5 ms·

Apple’s iPhone 5s, the A7 Chip, and That 64-Bit Question

31 points by r0h1n 13y ago

rayiner 13y ago
I think the journos are missing the point entirely here. Apple is playing up '64-bit' because it's an easy shorthand for people to understand. The salient benefit isn't the 64-bit address space per se, but the benefits of a next-generation architecture. Compare with ARM: the difference between Cortex A15 and Cortex A57 isn't just the register width or even ARMv8. The latter is a more sophisticated architecture overall. That's what Apple is using "64-bit" to refer to in this context--a post-Cortex A15-class chip.
- ajross 13y ago
  No. If that were the case then Apple would be selling the real technical stuff to a different market somewhere else. They're not, they just said "64 bit" and then clammed up. Basically, I don't see any evidence behind the "next generation architecture" stuff. Certainly ARMv8 itself isn't a huge leap -- it cleans some things up in the ISA (no more condition bits, IP is no longer a register, the multi-reg push/pop instructions are gone, ...) but as all of that is still required for 32 bit execution it isn't going to clean up the implementation on its own. If this is a great new CPU with great new features, they have to tell us that. I think the 64-bit messaging is really "shorthand" for what you wanted to hear from Apple. But you didn't, because they didn't say anything.
  - jrk 13y ago
    They did say something fairly concrete: they said it's "twice as fast" as the A6 in "CPU performance." This has nothing to do with virtual address size and pointer width (which only have a negative impact on relative performance, due to instruction encoding and pointer data bandwidth overhead), fairly little to do with ARMv8 vs. ARMv7 (which we know to make only a fairly modest difference—double the NEON register count is probably the biggest bump for interesting benchmarks), and a great deal to do with a combination of microarchitectural improvement and clock speed increases (early data trickling out strongly suggest it is 1.7Ghz in the 5s, vs. the Swift 1 cores' 1.3Ghz). So yes, by saying that it's "2x faster," Apple actually did fairly strongly say that it includes major microarchitectural improvements over the core design in the A6, much like we know there to be between the Cortex A15 and A57.
    - ajross 13y ago
      Shrug. My brain hears that kind of language in the same way that it heard "the G4 with Altivec is a supercomputer on your desk and blows away the competition" when of course it was a near-uniformly inferior CPU to its competitors. I'm sure it's faster. I don't believe 2x on general code at all. I half suspect they really mean 2x as fast on some crypto benchmark that can leverage wider word widths or something similarly inane. But I'm not going to claim that on a forum because, as mentioned, they haven't actually told us anything interesting. We're seriously supposed to have an informed discussion about CPU architecture based on marketing copy? No.
    - rayiner 13y ago
      Apple has always been cagey about its ARM CPUs. What we know about A6 was almost all reverse engineered. A lot is still conjecture.
    - MaysonL 13y ago
      UP TO 2x faster CPU and GPU performances.
- slantyyz 13y ago
  >> The salient benefit isn't the 64-bit address space per se, but the benefits of a next-generation architecture. This is what I thought too.. So is Gruber exaggerating when he says "There are serious performance gains by going 64-bit. Addressing more than 4 GB of memory is not the only advantage"? http://daringfireball.net/linked/2013/09/12/samsung-64 http://daringfireball.net/linked/2013/09/12/samsung-64
  - wmf 13y ago
    ARMv8 has twice as many registers which can improve performance.
    - UnoriginalGuy 13y ago
      Only available in 64 bit mode. Which most apps won't be.
      - glhaynes 13y ago
        Most, perhaps, if we're talking about the whole set of apps on the App Store. But I think it's very likely that the vast majority of very popular, "use 20 times a day" apps will be 64-bit very soon.
    - jrk 13y ago
      Yes, ARMv8 has twice as many architectural GPRs and NEON/FP registers, but: 1. This has nothing to do with 64-bitness, it could just as easily have been applied to a 32-bit iteration of the ARM ISA. (You're not saying it does, but many, including the linked article, do.) Widening the GPRs to 64-bits means that the number of bits of architectural register space is actually quadrupled (there are 2x as many, each of which is 2x as wide). 2. Performance scales (very) sublinearly with the number of available architectural registers. 3. The number of physical registers in the microarchitectural implementation may be unchanged, or may even be lower, than any given implementation of ARMv7. It is unlikely that this "Swift 2" core has fewer physical registers than the A6's "Swift 1", but ARMv8 just sets a higher lower-bound on the number of physical registers, and makes it modestly easier for a compiler to express a given piece of code with fewer spills. In reality, the number of physical GPRs in Swift 1 was likely already >= 32 due to register renaming (https://en.wikipedia.org/wiki/Register_renaming https://en.wikipedia.org/wiki/Register_renaming).
devx 13y ago
Android 4.4 is likely to get at the very least the Linux kernel 3.8 (if not 3.10), which includes support for ARMv8. Granted, that doesn't necessarily mean Android 4.4 will be "64-bit Android", and they'll probably wait at least until Android 5.0 for that (hopefully to be released no longer than Google I/O 2014). But I'm not sure if the kernel support will be enough for Android to be "64-bit", or if they need to make the Dalvik VM 64-bit, too? And can they even make Dalvik support both 64-bit and 32-bit, or how would that work? I've just read this part: > “This will not be true with Android, by the way. The Android Java app and native app environment will need support from Oracle, who owns the Java environment. That almost makes you disregard everything that guy said prior to that. He probably thinks Google is actually using the JVM.
- cageface 13y ago
  There are some real downsides to Dalvik/Java as a mobile toolkit, but at least the Android transition to 64-bit should be relatively smooth because there really shouldn't be too many apps out there now with the wrong assumptions about the size of ints & pointers. Native code is a different story, of course.
rythie 13y ago
At some point Apple is going to discontinue 32bit iOS - just like they did with OSX, they need about 3 years before they can do this. It makes sense to start early, because at some point they'll only be making devices with 4GB+ of memory (samsung already make 3GB phone).
- tadfisher 13y ago
  You don't need a 64-bit architecture to address more than 4GB of memory. The real benefit is the architecture update.
  - mikeash 13y ago
    You don't strictly need it, but you need it if you want a single app to be able to use more than 4GB of memory sanely.
  - reaperhulk 13y ago
    Unless your ARM has LPAE you do. I'm unsure if any ARMv7 chips out there are using LPAE yet? Anybody know? (Memory addressing info from ARM re: LPAE and ARMv8: http://infocenter.arm.com/help/topic/com.arm.doc.den0001c/DEN0001C_principles_of_arm_memory_maps.pdf http://infocenter.arm.com/help/topic/com.arm.doc.den0001c/DE...)
    - masklinn 13y ago
      The Cortex A7 and A15 support LPAE.
    - mbell 13y ago
      If you're addressing more than 4GB of physical memory (actually, ~3 to 3.5GB ish), you're using PAE, 32 vs 64 bit doesn't have any relevance to this. ARMv8 still uses a modified version of LPAE and x86_64 also uses an extension of PAE when running in 64bit mode. I don't know of a 64 bit architecture that doesn't use a PAE style table mapping system, i.e. none are directly addressing physical memory (I'm sure there is an arch out there somewhere that does, just not one I know of one in common use).
el_duderino 13y ago
Since everyone seems to have an opinion about the iPhone 5s having a 64-bit processor, here's mine. In the immediate future, this will make zero difference for consumers. Applications that ship today will continue to be compiled as 32-bit, so that they can run on all the other iOS devices as well. Since the iPhone 5s is likely to be faster than all those other iOS devices as well, there's little point right now optimizing an application for the iPhone 5s, everything that runs well enough on an iPhone 4s or iPhone 5 or iPhone 5c will run well enough on an iPhone 5s as well. Optimize for the low end, and the high end will take care if itself. In the medium term, there will come a moment in time when all supported iOS devices have 64-bit support, with Apple dropping support for 32-bit devices. At that point, the iPhone 5s will be the oldest supported iOS devices, and the iPhone 5c won't be supported any more. Indirectly, that means that the iPhone 5s will have a longer useful life than the iPhone 5c, and since the difference between 32-bit and 64-bit is qualitative and not quantitative, it's possible that the useful life of an iPhone 5s will be more than one year longer than that of the iPhone 5c. Users who care about how long they can keep their phones before being forced to replace them because of obsolescence could consider the more expensive iPhone 5s over an iPhone 5c on this point alone, regardless of the other differences. Finally, 64-bit support in the iPhone 5s is a great stepping stone for developers. Even though deploying 64-bit-only applications might not be practical for another few years, it's never too early to make sure that code compiles for 64-bit targets and passes all the unit tests, to run microbenchmarks, and maybe even for some dogfooding. In the long term, I can't rule out that Apple would remove 32-bit support entirely and would therefore mandate 64-bit applications, and it's probably easier to get ready on an ongoing basis than to go through a 64-bit fire drill many years down the road.
- mikeash 13y ago
  There is no need to wait for all iOS devices to be 64-bit. Push the button in Xcode and build a 32/64 fat app, and you get to run as 64-bit on the 5S, and 32-bit elsewhere.
- potatolicious 13y ago
  Agree with one correction: apps that are shipping in the near future will contain both 32- and 64-bit binaries (just like they contained both PowerPC/Intel binaries during the Mac transition). We'll realize these gains pretty quickly, though one major problem will be ensuring 64-bit compatibility across all your dependencies before committing to shipping 64-bit apps overall. I fully expect that the common dependencies (see: AFNetworking, Google Analytics, etc) will be 64-bit ready in, at most, a few months, at which point shipping a 64-bit app will be as simple as flipping a compile switch.
pohl 13y ago
The article only points out the double integer registers that AArch64 brings to the table. What interests me more are the doubled FP registers available to SIMD instructions. Would all of the image processing that is done automatically by the new camera software in the 5S have even been possible without this added performance? I suspect this is a benefit of AArch64 that can be directly linked to a specific user experience. In addition, there are other interesting across-the-board performance improvements enabled by 64bit pointers. Namely, the same one that they got on the desktop OS when Lion was introduced: Apple has apparently taken advantage of the 64-bit runtime in Lion by optimizing the Objective C runtime itself to use some of these extra bits for, shall we say, clever purposes. Bavarious describes an optimization through which Apple is able to replace previously full-fledged opaque objects such as NSNumber with an object-placeholder that exists entirely as the 64-bit “object address” itself. This means that, for a wide range of “simple” objects, no additional memory allocation is required, and no retain/release memory management is required for the “object.” http://www.red-sweater.com/blog/1947/bit-hacking http://www.red-sweater.com/blog/1947/bit-hacking
- deleted 13y ago
  [deleted]
- masklinn 13y ago
  > Namely, the same one that they got on the desktop OS when Lion was introduced: That's just a tagged pointer, language runtimes have been doing that for decades (lisp machines even had hardware support for tagged pointers)
  - pohl 13y ago
    Of course, but more bits provide more opportunities to do this. (I didn't mean to suggest that Apple invented tagged pointers. The question at hand was what benefits come from a 64bit processor.)
- ajross 13y ago
  Historically the delta between 16 and 32 GPRs has not made a huge difference to most algorithms (where the move from 8 to 16 was worth maybe 20% on typical code). Obviously there are outliers, but no: this was all hashed out in the early days of x86_64, when the early Athlons were turning in per-transistor-cycle performance numbers at or above what was seen in the RISC world. Basically: more registers means less spilling and filling to memory, but more work in context switches and for non-leaf function calls to save the extra data. It's all about tradeoffs. Note that no one ever went to a 64 GPR ISA (Itanium and Sparc have more than 32, but they do it with a stack engine that takes the work off the user code for the most part). ARMv8 is clean and nice, and 64 bit computation is clearly the future just as it is in the desktop world. But it's not a revolution (again, just as it wasn't in the desktop world) and we shouldn't try to make it one.
wiremine 13y ago
This sentence made me laugh a bit: "Finally, with the 64-bit A7, Apple has made it possible for developers to take the 64-bit apps they’ve written for the Mac and bring them to iOS 7 with relative ease." I guess I missed the whole "we're port your Mac Apps to the iPhone" part of the keynote.
- Cookingboy 13y ago
  A lot of code are very sharable between OS X and iOS apps. Sure the UI layer will be different, but many mid or low level libraries used for both iOS/OS X cross-platform apps are shared between them, and having both platforms supporting 64bit can open up that possibility even more.
  - wiremine 13y ago
    Yeah, I get that, I was just amused by the choice of "app" vs. "library".
kdot 13y ago
What are the chances of the iPhone 5S having 4GBs of RAM? iOS 7 is bringing multitasking support, potentially making more RAM necessary.
- masklinn 13y ago
  > What are the chances of the iPhone 5S having 4GBs of RAM? None. Apple is not going to quadruple RAM from one generation to the next.
jareds 13y ago
How much battery in a phone is used for RAM? What will the limit be assuming current incremental improvements in battery technology before it isn’t worth adding more RAM? When I heard this the first thing I thought of is that we may see an iPad with more than 4 gigs of memory since for video and audio editing that extra memory could make a big difference and the battery to power the RAM won’t be as big an issue in an iPad as in an iPhone.
- keeperofdakeys 13y ago
  Battery technology hasn't really moved anywhere in the last five years (even ten). So increasing battery capacity means a bigger battery. As for RAM, I found a good paper. http://www.nicta.com.au/pub?doc=3587 http://www.nicta.com.au/pub?doc=3587 If you go to the top of page 13, you'll see that RAM accounts for less than about 5% of all power usage. Given that cpus and radios in modern smartphones can use a bit more power, you're looking at even less. So I'd say ram is negligible towards power usage, so the amount doesn't have a power constraint.
musesum 13y ago
I've read that the NX (never execute) bit on some 64bit processors, may prevent some buffer overflow attacks. I wonder if this is available for the Apple A7 chip?
- jasomill 13y ago
  Yes, it is, but this is not new for the A7; it's also available on (all?) older iPhone CPUs. You're probably thinking about x86, where page-granular NX wasn't available until AMD64.
dmdeller 13y ago
> What about immediate improvements to battery life? Teich thinks that’s unlikely. “The only way battery life gets better with greater than 32-bit address spaces is to prevent swapping apps from physical memory to either SSD or HDD and then back again,” he said. iOS does not use a swap file[1] the way he is describing. [1]: https://developer.apple.com/library/ios/documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html https://developer.apple.com/library/ios/documentation/Perfor... - fourth paragraph
mgraczyk 13y ago
One interesting point that I haven't heard talked about nearly enough is that now Apple has ported its kernel and build infrastructure to A64. iOS and OS X share a great deal of code, so it wouldn't be crazy to predict that Apple may move to put their next generation of "Desktop Class" (hint hint) A64 chips in the Air or Macbook Pro. Now that Apple has their kernel running on a modern 64 bit architecture, it would almost be crazy for them NOT to focus on putting their specially optimized A8 core into their notebooks.
devx 13y ago
Mac devs, has Apple started doing anything that could show they're preparing to port Mac OS to ARM in the near future? I have this feeling Apple will "inevitably" put Mac OS on its own ARMv8 chips once they get "powerful enough" to sustain a "full OS" like Mac OS (they might wait until A8 or A9 to do that), and then sell like a $700 Air-like machine with keyboard and a larger screen than iPad, that would still be very profitable for them, because of how little an ARM chip costs compared to Intel Core chips. But I'm also certain Apple wouldn't do that if Mac apps wouldn't be easily ported to the ARM architecture. That's why I think Apple missed a big opportunity to ensure any Mac Store app is cross-platform between x64 and ARMv8 by default. But have they done anything recently under the hood that could make that possible anyway in the future?
- mikeash 13y ago
  I don't think there will be any advance signs. Nearly all of the CPU-specific stuff is common between Mac OS X and iOS, since that's generally in the kernel and low-level userspace libraries. The high-level stuff has been through multiple architecture transitions in the past few years (PPC->i386->x86-64) and any inadvertent architecture-specific assumptions in it has probably been ferreted out by now. Mac OS X is likely ready to go on ARM right now, with just a push of a button to build it. I'd be utterly shocked if Apple weren't maintaining an ARM build of OS X internally. If and when Apple decides to make an ARM-based Mac, we will probably only know it when it actually shows up, because the groundwork is fairly solid. The only thing that's lacking is encouraging third-party developers to cross-compile, and given Apple's famous secrecy, it's highly unlikely they'll give any advance warning just for that.
Symmetry 13y ago
That was a remarkably poor article. Doubling your registers won't get you anywhere near to doubling your performance on real world code, especially when you already have a decent number of registers like 16. Out of order chips like Apples that have caches they can hide the latency to in particular make this less of an issue. There are some integer loads that'll see something close to doubling performance from moving from 32 to 64 bit arithmetic, though. Also, Android doesn't use Oracle's JVM. It uses Dalvik which Oracle doesn't control. And Linux already supports 64-bit operation and has for a long time. It's only recently supported 64-bit ARM, though, and Android will need to grab a more recent version of the Linux kernel if they want to use 64-bit ARM. When Android supports 64-bit ARM they'll also benefit much more than Apple from the main advantage of 64-bit addressing when using less than 4 GB of memory: easier garbage collection. The larger your address space the less a random collection of bits will happen to constitute a valid pointer to a memory location.
- Steko 13y ago
  remarkably poor article. Doubling your registers won't get you anywhere near to doubling your performance on real world code Did you even read the article? "Double the register file adds a few percent to performance,” he said. “It’s a deep compiler and runtime VM issue. … So marginal improvements for most apps, at best."
  - Zarathust 13y ago
    The article has a lot of conflicting statements about this, which makes it rather poor. “This means that for some codes, the A7 will be twice as fast (or faster depending on how many memory accesses the original code had) to run code because the processor doesn’t have to use main memory as much.”
Steko 13y ago
Hey look another thread flagged down to oblivion by the we-hate-Apple HN mafia. (Thread should be in top 10 atm by votes, is #80-something)

31 points by r0h1n 13y ago

I think the journos are missing the point entirely here. Apple is playing up '64-bit' because it's an easy shorthand for people to understand. The salient benefit isn't the 64-bit address space per se, but the benefits of a next-generation architecture. Compare with ARM: the difference between Cortex A15 and Cortex A57 isn't just the register width or even ARMv8. The latter is a more sophisticated architecture overall. That's what Apple is using "64-bit" to refer to in this context--a post-Cortex A15-class chip.

ajross 13y ago
No. If that were the case then Apple would be selling the real technical stuff to a different market somewhere else. They're not, they just said "64 bit" and then clammed up. Basically, I don't see any evidence behind the "next generation architecture" stuff. Certainly ARMv8 itself isn't a huge leap -- it cleans some things up in the ISA (no more condition bits, IP is no longer a register, the multi-reg push/pop instructions are gone, ...) but as all of that is still required for 32 bit execution it isn't going to clean up the implementation on its own. If this is a great new CPU with great new features, they have to tell us that. I think the 64-bit messaging is really "shorthand" for what you wanted to hear from Apple. But you didn't, because they didn't say anything.
- jrk 13y ago
  They did say something fairly concrete: they said it's "twice as fast" as the A6 in "CPU performance." This has nothing to do with virtual address size and pointer width (which only have a negative impact on relative performance, due to instruction encoding and pointer data bandwidth overhead), fairly little to do with ARMv8 vs. ARMv7 (which we know to make only a fairly modest difference—double the NEON register count is probably the biggest bump for interesting benchmarks), and a great deal to do with a combination of microarchitectural improvement and clock speed increases (early data trickling out strongly suggest it is 1.7Ghz in the 5s, vs. the Swift 1 cores' 1.3Ghz). So yes, by saying that it's "2x faster," Apple actually did fairly strongly say that it includes major microarchitectural improvements over the core design in the A6, much like we know there to be between the Cortex A15 and A57.
  - ajross 13y ago
    Shrug. My brain hears that kind of language in the same way that it heard "the G4 with Altivec is a supercomputer on your desk and blows away the competition" when of course it was a near-uniformly inferior CPU to its competitors. I'm sure it's faster. I don't believe 2x on general code at all. I half suspect they really mean 2x as fast on some crypto benchmark that can leverage wider word widths or something similarly inane. But I'm not going to claim that on a forum because, as mentioned, they haven't actually told us anything interesting. We're seriously supposed to have an informed discussion about CPU architecture based on marketing copy? No.
  - rayiner 13y ago
    Apple has always been cagey about its ARM CPUs. What we know about A6 was almost all reverse engineered. A lot is still conjecture.
  - MaysonL 13y ago
    UP TO 2x faster CPU and GPU performances.
slantyyz 13y ago
>> The salient benefit isn't the 64-bit address space per se, but the benefits of a next-generation architecture. This is what I thought too.. So is Gruber exaggerating when he says "There are serious performance gains by going 64-bit. Addressing more than 4 GB of memory is not the only advantage"? http://daringfireball.net/linked/2013/09/12/samsung-64 http://daringfireball.net/linked/2013/09/12/samsung-64
- wmf 13y ago
  ARMv8 has twice as many registers which can improve performance.
  - UnoriginalGuy 13y ago
    Only available in 64 bit mode. Which most apps won't be.
    - glhaynes 13y ago
      Most, perhaps, if we're talking about the whole set of apps on the App Store. But I think it's very likely that the vast majority of very popular, "use 20 times a day" apps will be 64-bit very soon.
  - jrk 13y ago
    Yes, ARMv8 has twice as many architectural GPRs and NEON/FP registers, but: 1. This has nothing to do with 64-bitness, it could just as easily have been applied to a 32-bit iteration of the ARM ISA. (You're not saying it does, but many, including the linked article, do.) Widening the GPRs to 64-bits means that the number of bits of architectural register space is actually quadrupled (there are 2x as many, each of which is 2x as wide). 2. Performance scales (very) sublinearly with the number of available architectural registers. 3. The number of physical registers in the microarchitectural implementation may be unchanged, or may even be lower, than any given implementation of ARMv7. It is unlikely that this "Swift 2" core has fewer physical registers than the A6's "Swift 1", but ARMv8 just sets a higher lower-bound on the number of physical registers, and makes it modestly easier for a compiler to express a given piece of code with fewer spills. In reality, the number of physical GPRs in Swift 1 was likely already >= 32 due to register renaming (https://en.wikipedia.org/wiki/Register_renaming https://en.wikipedia.org/wiki/Register_renaming).

devx 13y ago

Android 4.4 is likely to get at the very least the Linux kernel 3.8 (if not 3.10), which includes support for ARMv8. Granted, that doesn't necessarily mean Android 4.4 will be "64-bit Android", and they'll probably wait at least until Android 5.0 for that (hopefully to be released no longer than Google I/O 2014). But I'm not sure if the kernel support will be enough for Android to be "64-bit", or if they need to make the Dalvik VM 64-bit, too? And can they even make Dalvik support both 64-bit and 32-bit, or how would that work? I've just read this part: > “This will not be true with Android, by the way. The Android Java app and native app environment will need support from Oracle, who owns the Java environment. That almost makes you disregard everything that guy said prior to that. He probably thinks Google is actually using the JVM.

cageface 13y ago
There are some real downsides to Dalvik/Java as a mobile toolkit, but at least the Android transition to 64-bit should be relatively smooth because there really shouldn't be too many apps out there now with the wrong assumptions about the size of ints & pointers. Native code is a different story, of course.

rythie 13y ago

At some point Apple is going to discontinue 32bit iOS - just like they did with OSX, they need about 3 years before they can do this. It makes sense to start early, because at some point they'll only be making devices with 4GB+ of memory (samsung already make 3GB phone).

tadfisher 13y ago
You don't need a 64-bit architecture to address more than 4GB of memory. The real benefit is the architecture update.
- mikeash 13y ago
  You don't strictly need it, but you need it if you want a single app to be able to use more than 4GB of memory sanely.
- reaperhulk 13y ago
  Unless your ARM has LPAE you do. I'm unsure if any ARMv7 chips out there are using LPAE yet? Anybody know? (Memory addressing info from ARM re: LPAE and ARMv8: http://infocenter.arm.com/help/topic/com.arm.doc.den0001c/DEN0001C_principles_of_arm_memory_maps.pdf http://infocenter.arm.com/help/topic/com.arm.doc.den0001c/DE...)
  - masklinn 13y ago
    The Cortex A7 and A15 support LPAE.
  - mbell 13y ago
    If you're addressing more than 4GB of physical memory (actually, ~3 to 3.5GB ish), you're using PAE, 32 vs 64 bit doesn't have any relevance to this. ARMv8 still uses a modified version of LPAE and x86_64 also uses an extension of PAE when running in 64bit mode. I don't know of a 64 bit architecture that doesn't use a PAE style table mapping system, i.e. none are directly addressing physical memory (I'm sure there is an arch out there somewhere that does, just not one I know of one in common use).

el_duderino 13y ago

Since everyone seems to have an opinion about the iPhone 5s having a 64-bit processor, here's mine. In the immediate future, this will make zero difference for consumers. Applications that ship today will continue to be compiled as 32-bit, so that they can run on all the other iOS devices as well. Since the iPhone 5s is likely to be faster than all those other iOS devices as well, there's little point right now optimizing an application for the iPhone 5s, everything that runs well enough on an iPhone 4s or iPhone 5 or iPhone 5c will run well enough on an iPhone 5s as well. Optimize for the low end, and the high end will take care if itself. In the medium term, there will come a moment in time when all supported iOS devices have 64-bit support, with Apple dropping support for 32-bit devices. At that point, the iPhone 5s will be the oldest supported iOS devices, and the iPhone 5c won't be supported any more. Indirectly, that means that the iPhone 5s will have a longer useful life than the iPhone 5c, and since the difference between 32-bit and 64-bit is qualitative and not quantitative, it's possible that the useful life of an iPhone 5s will be more than one year longer than that of the iPhone 5c. Users who care about how long they can keep their phones before being forced to replace them because of obsolescence could consider the more expensive iPhone 5s over an iPhone 5c on this point alone, regardless of the other differences. Finally, 64-bit support in the iPhone 5s is a great stepping stone for developers. Even though deploying 64-bit-only applications might not be practical for another few years, it's never too early to make sure that code compiles for 64-bit targets and passes all the unit tests, to run microbenchmarks, and maybe even for some dogfooding. In the long term, I can't rule out that Apple would remove 32-bit support entirely and would therefore mandate 64-bit applications, and it's probably easier to get ready on an ongoing basis than to go through a 64-bit fire drill many years down the road.

mikeash 13y ago
There is no need to wait for all iOS devices to be 64-bit. Push the button in Xcode and build a 32/64 fat app, and you get to run as 64-bit on the 5S, and 32-bit elsewhere.
potatolicious 13y ago
Agree with one correction: apps that are shipping in the near future will contain both 32- and 64-bit binaries (just like they contained both PowerPC/Intel binaries during the Mac transition). We'll realize these gains pretty quickly, though one major problem will be ensuring 64-bit compatibility across all your dependencies before committing to shipping 64-bit apps overall. I fully expect that the common dependencies (see: AFNetworking, Google Analytics, etc) will be 64-bit ready in, at most, a few months, at which point shipping a 64-bit app will be as simple as flipping a compile switch.

pohl 13y ago

The article only points out the double integer registers that AArch64 brings to the table. What interests me more are the doubled FP registers available to SIMD instructions. Would all of the image processing that is done automatically by the new camera software in the 5S have even been possible without this added performance? I suspect this is a benefit of AArch64 that can be directly linked to a specific user experience. In addition, there are other interesting across-the-board performance improvements enabled by 64bit pointers. Namely, the same one that they got on the desktop OS when Lion was introduced: Apple has apparently taken advantage of the 64-bit runtime in Lion by optimizing the Objective C runtime itself to use some of these extra bits for, shall we say, clever purposes. Bavarious describes an optimization through which Apple is able to replace previously full-fledged opaque objects such as NSNumber with an object-placeholder that exists entirely as the 64-bit “object address” itself. This means that, for a wide range of “simple” objects, no additional memory allocation is required, and no retain/release memory management is required for the “object.” http://www.red-sweater.com/blog/1947/bit-hacking http://www.red-sweater.com/blog/1947/bit-hacking

deleted 13y ago
[deleted]
masklinn 13y ago
> Namely, the same one that they got on the desktop OS when Lion was introduced: That's just a tagged pointer, language runtimes have been doing that for decades (lisp machines even had hardware support for tagged pointers)
- pohl 13y ago
  Of course, but more bits provide more opportunities to do this. (I didn't mean to suggest that Apple invented tagged pointers. The question at hand was what benefits come from a 64bit processor.)
ajross 13y ago
Historically the delta between 16 and 32 GPRs has not made a huge difference to most algorithms (where the move from 8 to 16 was worth maybe 20% on typical code). Obviously there are outliers, but no: this was all hashed out in the early days of x86_64, when the early Athlons were turning in per-transistor-cycle performance numbers at or above what was seen in the RISC world. Basically: more registers means less spilling and filling to memory, but more work in context switches and for non-leaf function calls to save the extra data. It's all about tradeoffs. Note that no one ever went to a 64 GPR ISA (Itanium and Sparc have more than 32, but they do it with a stack engine that takes the work off the user code for the most part). ARMv8 is clean and nice, and 64 bit computation is clearly the future just as it is in the desktop world. But it's not a revolution (again, just as it wasn't in the desktop world) and we shouldn't try to make it one.

wiremine 13y ago

This sentence made me laugh a bit: "Finally, with the 64-bit A7, Apple has made it possible for developers to take the 64-bit apps they’ve written for the Mac and bring them to iOS 7 with relative ease." I guess I missed the whole "we're port your Mac Apps to the iPhone" part of the keynote.

Cookingboy 13y ago
A lot of code are very sharable between OS X and iOS apps. Sure the UI layer will be different, but many mid or low level libraries used for both iOS/OS X cross-platform apps are shared between them, and having both platforms supporting 64bit can open up that possibility even more.
- wiremine 13y ago
  Yeah, I get that, I was just amused by the choice of "app" vs. "library".

kdot 13y ago

What are the chances of the iPhone 5S having 4GBs of RAM? iOS 7 is bringing multitasking support, potentially making more RAM necessary.

masklinn 13y ago
> What are the chances of the iPhone 5S having 4GBs of RAM? None. Apple is not going to quadruple RAM from one generation to the next.

jareds 13y ago

How much battery in a phone is used for RAM? What will the limit be assuming current incremental improvements in battery technology before it isn’t worth adding more RAM? When I heard this the first thing I thought of is that we may see an iPad with more than 4 gigs of memory since for video and audio editing that extra memory could make a big difference and the battery to power the RAM won’t be as big an issue in an iPad as in an iPhone.

keeperofdakeys 13y ago
Battery technology hasn't really moved anywhere in the last five years (even ten). So increasing battery capacity means a bigger battery. As for RAM, I found a good paper. http://www.nicta.com.au/pub?doc=3587 http://www.nicta.com.au/pub?doc=3587 If you go to the top of page 13, you'll see that RAM accounts for less than about 5% of all power usage. Given that cpus and radios in modern smartphones can use a bit more power, you're looking at even less. So I'd say ram is negligible towards power usage, so the amount doesn't have a power constraint.

musesum 13y ago

I've read that the NX (never execute) bit on some 64bit processors, may prevent some buffer overflow attacks. I wonder if this is available for the Apple A7 chip?

jasomill 13y ago
Yes, it is, but this is not new for the A7; it's also available on (all?) older iPhone CPUs. You're probably thinking about x86, where page-granular NX wasn't available until AMD64.

dmdeller 13y ago

> What about immediate improvements to battery life? Teich thinks that’s unlikely. “The only way battery life gets better with greater than 32-bit address spaces is to prevent swapping apps from physical memory to either SSD or HDD and then back again,” he said. iOS does not use a swap file[1] the way he is describing. [1]: https://developer.apple.com/library/ios/documentation/Performance/Conceptual/ManagingMemory/Articles/AboutMemory.html https://developer.apple.com/library/ios/documentation/Perfor... - fourth paragraph

mgraczyk 13y ago

One interesting point that I haven't heard talked about nearly enough is that now Apple has ported its kernel and build infrastructure to A64. iOS and OS X share a great deal of code, so it wouldn't be crazy to predict that Apple may move to put their next generation of "Desktop Class" (hint hint) A64 chips in the Air or Macbook Pro. Now that Apple has their kernel running on a modern 64 bit architecture, it would almost be crazy for them NOT to focus on putting their specially optimized A8 core into their notebooks.

devx 13y ago

Mac devs, has Apple started doing anything that could show they're preparing to port Mac OS to ARM in the near future? I have this feeling Apple will "inevitably" put Mac OS on its own ARMv8 chips once they get "powerful enough" to sustain a "full OS" like Mac OS (they might wait until A8 or A9 to do that), and then sell like a $700 Air-like machine with keyboard and a larger screen than iPad, that would still be very profitable for them, because of how little an ARM chip costs compared to Intel Core chips. But I'm also certain Apple wouldn't do that if Mac apps wouldn't be easily ported to the ARM architecture. That's why I think Apple missed a big opportunity to ensure any Mac Store app is cross-platform between x64 and ARMv8 by default. But have they done anything recently under the hood that could make that possible anyway in the future?

mikeash 13y ago
I don't think there will be any advance signs. Nearly all of the CPU-specific stuff is common between Mac OS X and iOS, since that's generally in the kernel and low-level userspace libraries. The high-level stuff has been through multiple architecture transitions in the past few years (PPC->i386->x86-64) and any inadvertent architecture-specific assumptions in it has probably been ferreted out by now. Mac OS X is likely ready to go on ARM right now, with just a push of a button to build it. I'd be utterly shocked if Apple weren't maintaining an ARM build of OS X internally. If and when Apple decides to make an ARM-based Mac, we will probably only know it when it actually shows up, because the groundwork is fairly solid. The only thing that's lacking is encouraging third-party developers to cross-compile, and given Apple's famous secrecy, it's highly unlikely they'll give any advance warning just for that.

Symmetry 13y ago

That was a remarkably poor article. Doubling your registers won't get you anywhere near to doubling your performance on real world code, especially when you already have a decent number of registers like 16. Out of order chips like Apples that have caches they can hide the latency to in particular make this less of an issue. There are some integer loads that'll see something close to doubling performance from moving from 32 to 64 bit arithmetic, though. Also, Android doesn't use Oracle's JVM. It uses Dalvik which Oracle doesn't control. And Linux already supports 64-bit operation and has for a long time. It's only recently supported 64-bit ARM, though, and Android will need to grab a more recent version of the Linux kernel if they want to use 64-bit ARM. When Android supports 64-bit ARM they'll also benefit much more than Apple from the main advantage of 64-bit addressing when using less than 4 GB of memory: easier garbage collection. The larger your address space the less a random collection of bits will happen to constitute a valid pointer to a memory location.

Steko 13y ago
remarkably poor article. Doubling your registers won't get you anywhere near to doubling your performance on real world code Did you even read the article? "Double the register file adds a few percent to performance,” he said. “It’s a deep compiler and runtime VM issue. … So marginal improvements for most apps, at best."
- Zarathust 13y ago
  The article has a lot of conflicting statements about this, which makes it rather poor. “This means that for some codes, the A7 will be twice as fast (or faster depending on how many memory accesses the original code had) to run code because the processor doesn’t have to use main memory as much.”

Steko 13y ago

Hey look another thread flagged down to oblivion by the we-hate-Apple HN mafia. (Thread should be in top 10 atm by votes, is #80-something)