4 ms·

>> 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 ex

>> 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).
UnoriginalGuy 13y ago
Yes, exaggerating is a nice way of putting it. Plus a lot of people are ignoring the fact that 64 bit means that everything in 64 bit mode consumes more RAM and more storage space. e.g. - Shell32.dll (Windows 64): 18.8 MB - Shell32.dll (Windows 32): 16.7 MB 13% increase in size. This applied to every binary on the system both in RAM and in storage (assuming you don't need two copies for 32 bit compatibility which is highly highly likely). So if they increase the RAM on the iPhone 5S almost all of the "increase" might be consumed by the new 64 bit migration and if they have a 32 bit compatibility mode running then you're talking about having less free RAM than the old iPhone did for apps etc.
- pohl 13y ago
  How could a 13% increase in size consume almost all of a resources they would likely double?
  - UnoriginalGuy 13y ago
    It is actually nearer to 113%. They have the existing 32 bit stuff from the old iOS for compatibility reasons and the new 64 bit stuff which is 13% larger than the old stuff. Apple, as far as I know, haven't released how much RAM they'll be adding to the 5S. If they double the iPhone 5's RAM this might all be a non-issue, but you still won't gain as much free as you might initially imagine per above.
    - pohl 13y ago
      I'm still not following your math. On a clean phone none of those 32bit libraries will be resident in memory, since all of their own apps are already updated. If a user starts an older 3rd-party app then that process will incur some overhead, until it exits. Since Apple's frameworks have already been through this transition on the desktop, the average 3rd party app will likely make this transition easily with a build target setting. I'm sure older games, like the original Infinity Blade, may never make this transition. I doubt any users will notice, though.
mikeash 13y ago
He's saying the same thing the comment you're replying to is saying. "64-bit" doesn't just mean larger pointers, but encompasses the whole of the architectural changes in the new chip and instruction set. Those are far more important than just bigger pointers.

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).

UnoriginalGuy 13y ago

Yes, exaggerating is a nice way of putting it. Plus a lot of people are ignoring the fact that 64 bit means that everything in 64 bit mode consumes more RAM and more storage space. e.g. - Shell32.dll (Windows 64): 18.8 MB - Shell32.dll (Windows 32): 16.7 MB 13% increase in size. This applied to every binary on the system both in RAM and in storage (assuming you don't need two copies for 32 bit compatibility which is highly highly likely). So if they increase the RAM on the iPhone 5S almost all of the "increase" might be consumed by the new 64 bit migration and if they have a 32 bit compatibility mode running then you're talking about having less free RAM than the old iPhone did for apps etc.

pohl 13y ago
How could a 13% increase in size consume almost all of a resources they would likely double?
- UnoriginalGuy 13y ago
  It is actually nearer to 113%. They have the existing 32 bit stuff from the old iOS for compatibility reasons and the new 64 bit stuff which is 13% larger than the old stuff. Apple, as far as I know, haven't released how much RAM they'll be adding to the 5S. If they double the iPhone 5's RAM this might all be a non-issue, but you still won't gain as much free as you might initially imagine per above.
  - pohl 13y ago
    I'm still not following your math. On a clean phone none of those 32bit libraries will be resident in memory, since all of their own apps are already updated. If a user starts an older 3rd-party app then that process will incur some overhead, until it exits. Since Apple's frameworks have already been through this transition on the desktop, the average 3rd party app will likely make this transition easily with a build target setting. I'm sure older games, like the original Infinity Blade, may never make this transition. I doubt any users will notice, though.

mikeash 13y ago

He's saying the same thing the comment you're replying to is saying. "64-bit" doesn't just mean larger pointers, but encompasses the whole of the architectural changes in the new chip and instruction set. Those are far more important than just bigger pointers.