4 ms·

> Since a 64-bit processor processes more data at a time than a 32-bit processor, you get faster performance. Is this true? If I recall correctly, 32-bit to 64

> Since a 64-bit processor processes more data at a time than a 32-bit processor, you get faster performance. Is this true? If I recall correctly, 32-bit to 64-bit doesn't always necessarily mean "end-user performance improvements."

fulafel 10y ago
It's false - if you want to process many bits at once, you use SIMD instructions, which you have on 32-bit too. Generally, other things equal, going from 32 to 64 bit word size makes things slower because pointers suddenly double in size, and you can fit fewer program objects in your caches. In practice there are a slew of miscellaneous improvements in the new 64-bit revision of an instruction set that makes up for some of the slowdown. This is less pronounced on ARM, but was big on x86 because a big flaw, the register count, was fixed.
- Sanddancer 10y ago
  However, ARMv8 also increased the power of the SIMD portion of the chip, going from a 64 bit wide set of registers to one that's 128 bits wide. So SIMD-heavy code will see a decent speedup because you can process more data per clock.
  - fulafel 10y ago
    128-bit NEON has been available on 32-bit ARM for a long time, since Cortex-A8 (2005) or so.
Sanddancer 10y ago
Yep. If it's just 32->64 there may even be a slow down as you need to pull bigger things through the various busses. However, Armv8 also brought a huge improvement to the instruction set, so recompiling with the proper optimizations will bring performance increases in a lot of programs.
xenadu02 10y ago
sigh Technically it doesn't. In practice only two architectures matter: x86 and ARM. Both brought cleaned-up ISAs, expanded the number of general-purpose registers, made some features required, and made other improvements during the transition. So for all practical purposes: YES, the 64-bit transition has actual real benefits to end users besides the larger address space.
- cameldrv 10y ago
  Assuming you don't need the extra address space, what are those? End-user improvements that is... Performance wise, I doubt that the performance gains from extra registers make up for the higher cache miss rate from the larger code and data sizes.
  - pjmlp 10y ago
    Improved security with care for performance, little things like SGX, MPX, IO and GPU DMA in hypervisors, for example.
    - saurik 10y ago
      How about coming up with an example for ARM, one that doesn't come from using the new chipset but which requires the new instruction set (and particularly one which somehow precludes supporting older applications). AFAIK, ARM64 maybe offers some minor benefits to floating point operations, but mostly just provides access to some more registers... an advantage which sometimes matters but is often so dubious that on 32-bit ARM a lot of performance oriented code would be compiled to Thumb-1 even though it had half as many registers, as the code would load faster and take up less space in the cache.
      - pjmlp 10y ago
        Parent stated: > In practice only two architectures matter: x86 and ARM. So I replied about x86, because that is the architecture I know best.
  - 10y ago
elihu 10y ago
In x86, there is even an ABI for using 64-bit instruction set features (like more registers) while sticking with 32-bit pointers to keep the memory footprint small and fast. (This limits you to 4GB of ram per process, but there are a lot of applications where that's not particularly important.) https://en.wikipedia.org/wiki/X32_ABI https://en.wikipedia.org/wiki/X32_ABI https://lwn.net/Articles/456731/ https://lwn.net/Articles/456731/
- zurn 10y ago
  x86 is a special case because 32-bit x86 was exceptionally register-starved, causing a performance penalty. (That said, the "x32" ABI is not widely used)
ytch 10y ago
Not completely true, AArch64 performs better because it has more registers (means less fetch from memory), and more advanced instructions. Here is an article about this: https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-an...
dspillett 10y ago
It is a big fat "it depends". If you don't need the extra data width then in theory 32-bit code could be faster as smaller units are being loaded from cache or main memory. But depending on your architecture there could be alignment related performance issues that 32-bit instructions will run into but 64-bit ones will not because the memory fetch portions of the processor and related subsystems are optimised for 64-bit alignment. A 32-bit application is going to be older too and won't be using non-64-bit-specific enhancements present in the processor families that may help it more than being able to deal with bigger integers. More registers being available for instance, additional SIMD instructions (for doing more with collections of smaller values) or wider versions of existing SIMD instructions. There may be other architecture dependant factors to consider too. Other considerations come from running 32-bit apps on systems that support both 64 and 32: you end up with two versions of some libraries in RAM which could give a one-off hit upon loading an app but also means more memory pressure so other stuff could be being pushed out and will need to be reloaded later from slower storage later when next called. That won't matter for libraries that one one app is using anyway, but for shared system libraries it could be significant. Also if the 32-bit libraries are really just a translation layer calling the 64-bit ones, then there is extra work per call that isn't related to how many bits you can process in one instruction. The extra memory pressure may slow down other apps when you switch back to them (via user action or due to them having a background service portion that needs to respond to an event) as more pages need to be reloaded from slower storage instead of already being in RAM, meaning the slow down the warning is talking about may not be immediate or affect the current app at all. "64-bit gets faster performance because you can do twice as much in one step" is a useful explanation for the general public, one that is true (or at least not completely false), easy to understand, and much simpler than the larger collection of real details. A bit like in GCSE physics when you are told "yeah, what we said in science lessons before is a simplification and on some levels actually wrong, this is what really happens" and in A-Level physics you are told "yeah, what we said at GCSE level is a simplification and on some levels actually wrong, this is what really happens" and so on up your education as far as you take it. The simplification is needed to get the message across to those who don't need or care to know more, but doesn't hold as much water upon more detailed inspection. I think talking about the performance hit is a mistaken way of talking to the users about the matter though because for a great many cases on an iPhone that is unlikely to be significant as the reporter here notes. And even if there is an effect overall the common user will not notice an immediate effect and assume going forward that there is no effect at all and that the warning was being over sensitive. A better way to get the message over on an iDevice is to point out that more battery power will be consumed. This is equally true (if not more so) and people are likely to care more IME.
readittwice 10y ago
Sure, but don't forget that there also exists aarch64 with ilp32 (int, long and pointers are 32bit) as opposed to the default lp64. Which is basically the new instruction set but restricted to 32bit memory space. In fact some of the specint benchmarks are faster with ilp32.

fulafel 10y ago

It's false - if you want to process many bits at once, you use SIMD instructions, which you have on 32-bit too. Generally, other things equal, going from 32 to 64 bit word size makes things slower because pointers suddenly double in size, and you can fit fewer program objects in your caches. In practice there are a slew of miscellaneous improvements in the new 64-bit revision of an instruction set that makes up for some of the slowdown. This is less pronounced on ARM, but was big on x86 because a big flaw, the register count, was fixed.

Sanddancer 10y ago
However, ARMv8 also increased the power of the SIMD portion of the chip, going from a 64 bit wide set of registers to one that's 128 bits wide. So SIMD-heavy code will see a decent speedup because you can process more data per clock.
- fulafel 10y ago
  128-bit NEON has been available on 32-bit ARM for a long time, since Cortex-A8 (2005) or so.

Sanddancer 10y ago

Yep. If it's just 32->64 there may even be a slow down as you need to pull bigger things through the various busses. However, Armv8 also brought a huge improvement to the instruction set, so recompiling with the proper optimizations will bring performance increases in a lot of programs.

xenadu02 10y ago

sigh Technically it doesn't. In practice only two architectures matter: x86 and ARM. Both brought cleaned-up ISAs, expanded the number of general-purpose registers, made some features required, and made other improvements during the transition. So for all practical purposes: YES, the 64-bit transition has actual real benefits to end users besides the larger address space.

cameldrv 10y ago
Assuming you don't need the extra address space, what are those? End-user improvements that is... Performance wise, I doubt that the performance gains from extra registers make up for the higher cache miss rate from the larger code and data sizes.
- pjmlp 10y ago
  Improved security with care for performance, little things like SGX, MPX, IO and GPU DMA in hypervisors, for example.
  - saurik 10y ago
    How about coming up with an example for ARM, one that doesn't come from using the new chipset but which requires the new instruction set (and particularly one which somehow precludes supporting older applications). AFAIK, ARM64 maybe offers some minor benefits to floating point operations, but mostly just provides access to some more registers... an advantage which sometimes matters but is often so dubious that on 32-bit ARM a lot of performance oriented code would be compiled to Thumb-1 even though it had half as many registers, as the code would load faster and take up less space in the cache.
    - pjmlp 10y ago
      Parent stated: > In practice only two architectures matter: x86 and ARM. So I replied about x86, because that is the architecture I know best.
- 10y ago

elihu 10y ago

In x86, there is even an ABI for using 64-bit instruction set features (like more registers) while sticking with 32-bit pointers to keep the memory footprint small and fast. (This limits you to 4GB of ram per process, but there are a lot of applications where that's not particularly important.) https://en.wikipedia.org/wiki/X32_ABI https://en.wikipedia.org/wiki/X32_ABI https://lwn.net/Articles/456731/ https://lwn.net/Articles/456731/

zurn 10y ago
x86 is a special case because 32-bit x86 was exceptionally register-starved, causing a performance penalty. (That said, the "x32" ABI is not widely used)

ytch 10y ago

Not completely true, AArch64 performs better because it has more registers (means less fetch from memory), and more advanced instructions. Here is an article about this: https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-and-you.html https://www.mikeash.com/pyblog/friday-qa-2013-09-27-arm64-an...

dspillett 10y ago

It is a big fat "it depends". If you don't need the extra data width then in theory 32-bit code could be faster as smaller units are being loaded from cache or main memory. But depending on your architecture there could be alignment related performance issues that 32-bit instructions will run into but 64-bit ones will not because the memory fetch portions of the processor and related subsystems are optimised for 64-bit alignment. A 32-bit application is going to be older too and won't be using non-64-bit-specific enhancements present in the processor families that may help it more than being able to deal with bigger integers. More registers being available for instance, additional SIMD instructions (for doing more with collections of smaller values) or wider versions of existing SIMD instructions. There may be other architecture dependant factors to consider too. Other considerations come from running 32-bit apps on systems that support both 64 and 32: you end up with two versions of some libraries in RAM which could give a one-off hit upon loading an app but also means more memory pressure so other stuff could be being pushed out and will need to be reloaded later from slower storage later when next called. That won't matter for libraries that one one app is using anyway, but for shared system libraries it could be significant. Also if the 32-bit libraries are really just a translation layer calling the 64-bit ones, then there is extra work per call that isn't related to how many bits you can process in one instruction. The extra memory pressure may slow down other apps when you switch back to them (via user action or due to them having a background service portion that needs to respond to an event) as more pages need to be reloaded from slower storage instead of already being in RAM, meaning the slow down the warning is talking about may not be immediate or affect the current app at all. "64-bit gets faster performance because you can do twice as much in one step" is a useful explanation for the general public, one that is true (or at least not completely false), easy to understand, and much simpler than the larger collection of real details. A bit like in GCSE physics when you are told "yeah, what we said in science lessons before is a simplification and on some levels actually wrong, this is what really happens" and in A-Level physics you are told "yeah, what we said at GCSE level is a simplification and on some levels actually wrong, this is what really happens" and so on up your education as far as you take it. The simplification is needed to get the message across to those who don't need or care to know more, but doesn't hold as much water upon more detailed inspection. I think talking about the performance hit is a mistaken way of talking to the users about the matter though because for a great many cases on an iPhone that is unlikely to be significant as the reporter here notes. And even if there is an effect overall the common user will not notice an immediate effect and assume going forward that there is no effect at all and that the warning was being over sensitive. A better way to get the message over on an iDevice is to point out that more battery power will be consumed. This is equally true (if not more so) and people are likely to care more IME.

readittwice 10y ago

Sure, but don't forget that there also exists aarch64 with ilp32 (int, long and pointers are 32bit) as opposed to the default lp64. Which is basically the new instruction set but restricted to 32bit memory space. In fact some of the specint benchmarks are faster with ilp32.