Qualcomm backtracks from Apple A7 marketing gimmick comments | Hacker News Reader

Qualcomm backtracks from Apple A7 marketing gimmick comments

techhive.com

42 pointskposehn29 comments

Nobody seems to be saying this here so I'll just come out and say it...

Qualcomm's knee jerk reaction to press that praises Apple's platform is to point out the obviously premature move to 64 bit mobile chips, since Apple does not buy Qcomm SOCs and competes with Samsung, Qcomm's biggest customer. After a little critical thinking, Qualcomm realizes that it too will shortly be selling 64 bit mobile chips because now Samsung will want to match apple spec for spec, as most Android OEMs typically do.

--------------------------- As whether the move was a "gimmick" or not: The move to 64 bit would have been premature if Microsoft or an Android OEM had done it, but Apple made the right call for a few reasons:

(the obvious) - ARM v8 is a new ISA, and porting 32-bit ARM kernel code to the new ISA just to abandon it in a few years would be foolish

(musing)- Apple's OS people now only have to worry about one kernel code base when writing non-assembly, non performance critical code.

(speculation) - Apple may consider switching some of their traditionally x86 lineup to use lower power ARM chips in the intermediate future (2-4 years) and is giving itself that option by getting their kernel ready for ARM 64.

(way out there) - Apple may be planning to use their mobile chips in ultra low power server clusters, and they had to port the kernel to 64 bit before that was an option.

In "the obvious", note that the switch to ARM64 also allows a more efficient Obj-C runtime: there are more unused bits (due to alignment and effective pointer sizes) in AArch64 than in AArch32, and more in ARM64 than x86-64.

This allows the obj-c runtime to smuggle significantly more information inline in the `isa` pointer on ARM64 than on ARM32 or x86-64 (via pointer tagging): http://www.sealiesoftware.com/blog/archive/2013/09/24/objc_e... http://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and...

(amongst other things, 19 bits of the pointer are now used to hold the object's reference count, for any object with less than half a million references an incref or decref is just an atomic increment or decrement of this field, instead of an indirection through a global refcount table with a bunch of locks involved)

> In "the obvious", note that the switch to ARM64 also allows a more efficient Obj-C runtime […]

Why wouldn’t inline reference counts (as an extra 32 bit word in the object struct) be just as effective on a 32 bit architecture?

Apple’s tagged pointer tricks are just making the best of a bad situation.

Most definitely. If you were building a new environment from scratch, there's no reason you couldn't do the same basic stuff in a 32-bit world. Apple just couldn't do it without the architecture transition because it would break everything.

How are extra 32bit words considered "inline"? Wouldn't this completely miss using the register for count evaluation?

> (musing)- Apple's OS people now only have to worry about one kernel code base when writing non-assembly, non performance critical code.

iOS and Mac OS X have shared most of the kernel code for years. I doubt this makes any difference.

That wasn't a very useful article in terms of explaining the potential benefits of 64-bit on mobile. I get that the reasons are a bit esoteric; "a larger address space makes ASLR more effective" is tough to explain to a non-programmer reader. But a writer's job is to get people who understand to explain and then write that explanation in a way that readers can roughly understand.

Agree. Going 64-bits in general can benefit that more instruction sets, more data sets per instruction, memory access at repeating process. What's in this article is just quote by CMO that is a claim without benchmark evidence or whatever.

Unnamed sources at the company said that Anand Chandrasekher would be receiving a well-deserved spanking.

As long as the spankings remain within the "Chandrasekher Limit" I don't think we are in danger of dwarfing the larger issues.

Gruber must be feeling pretty smug right now: http://daringfireball.net/linked/2013/10/02/qualcomm-a7

Yep: http://daringfireball.net/linked/2013/10/08/qualcomm

"...for compatibility reasons, we still support the entire ARMv7 machine in the new ARMv8 architecture, but when running 64-bit software, this part of the machine is not being used, and the area of complex legacy it had built up does not need to be active when running in the 64-bit ISA, unlike other architectures where 64-bit extension was simply added to the historical complexity and legacy of their 32-bit mode. The new ISA drew upon the years of experience of building different micro architecture implementations, so again it was defined so that these new processors can be more easily optimized for low power operation — an opportunity not really offered since the first ARMv4 machine that resulted in the now legendary low power ARM7 processors."

http://www.arm.com/files/downloads/ARMv8_white_paper_v5.pdf

That was a terrible comment from Anand Chandrasekher and shows fundamental lack of understanding. How did he become the CMO?

Qualcomm supplies the modem/baseband chips in iPhones (at least the iPhone 4 and 5), so I imagine they wouldn't want to upset a customer too much.

> A benefit of 64-bit is the ability to put more than 4GB of memory in smartphones

This is an annoying piece of misinformation that always rears its ugly head in 64-bit discussions. There are many ways to address more than 4GB of memory, going 64-bit is far from the only option.

True, but they're usually far from the most elegant or speedy option.

64bit move comes along with ARM v8 move. It wouldn't make sense for apple to move to ARM v8 staying at 32bit. As far as I remember apple hasn't said that 2x performance improvement came from just 64bit. They included new ISA and 64bit compatible iOS 7 too.

Well, there are actually some reasons to stay with 32 bit when using AArch64 in ARM v8. There are lots of goodies in the new, RISCier encodings and the benefits from the more traditional encoding are more relevant for lower-end chips. I'm sort of waiting for someone to make an ARM equivalent of the x32 ABI[1], using the new instructions but keeping 32-bit pointers to minimize cache pressure.

Still, 64-bit memory addressing does have advantages in terms of garbage collection, mmaping files, etc even if the phone has less than 1 GB of RAM.

[1]http://en.wikipedia.org/wiki/X32_ABI

Lessons from my father: Shit is best eaten in small bites, as it is served.

Zero credibility all around. I hope to see some proper details on how exactly this helps mobile applications.

http://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and...

Also: http://www.anandtech.com/show/7335/the-iphone-5s-review/4

From the conclusion: The simple fact of moving to 64-bit does little. It makes for slightly faster computations in some cases, somewhat higher memory usage for most programs, and makes certain programming techniques more viable. Overall, it's not hugely significant.

So it isn't a huge deal. It's the overall package that adds up to a much faster SOC.

Right, but it's the overall package made possible by moving to a new 64-bit architecture.

It's a subtle distinction that can be hard to communicate, but while "64-bit" is not all that interesting, "moving to 64-bit" is in this case.

A lot of the improvement wouldn't be possible without the new architecture. In theory, you could do a new 32-bit architecture that has all the same benefits, but that would be terribly pointless.

(I see the author of the piece you quoted has responded also.)

Really, it's not just the SOC.

As described in @mikeash's piece, the 64-bit address length has allowed Apple to inline some per-object information (like reference counts) with object pointers, which is a big win in some key operations (2x faster object creation/destruction), which could sometimes make a big difference at the application level.

Reply on news.ycombinator.com