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.
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.
In short, changing architecture is big and they changed multiple things. The new architecture is 64 bit but it's actually some of the other changes that will help the most. So what Apple changed will make a substantial difference, but most of the improvement isn't well explained by saying "now we have 64 bits".
I really cannot see how one can dismiss the tagged pointers and runtime changes out of hand. Add to that the non-word size changes and Qualcomm's sour grapes is just a "not there first" PR statement.
Registers twice as big? Tagged pointers allowing more classes to be tucked into registers? Actual benchmarks showing significant performance gains? What exactly does it take?
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.
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.
(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)
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.
"...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."
> 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.
34 comments
[ 3.1 ms ] story [ 105 ms ] threadSo it isn't a huge deal. It's the overall package that adds up to a much faster SOC.
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.
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.
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
In short, changing architecture is big and they changed multiple things. The new architecture is 64 bit but it's actually some of the other changes that will help the most. So what Apple changed will make a substantial difference, but most of the improvement isn't well explained by saying "now we have 64 bits".
Registers twice as big? Tagged pointers allowing more classes to be tucked into registers? Actual benchmarks showing significant performance gains? What exactly does it take?
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.
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)
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.
iOS and Mac OS X have shared most of the kernel code for years. I doubt this makes any difference.
http://www.arm.com/files/downloads/ARMv8_white_paper_v5.pdf
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.