1. For DSP / image processing, 64-bit SIMD allows you to operate on twice as many elements as 32-bit SIMD
I think this is very much wrong. You do get more SIMD registers, but both 32-bit and 64-bit ARM have 128 bits wide SIMD registers. Same number of elements per instruction.
2. For normal computing, you get 31 64-bit registers instead of 15 32-bit registers (essentially 4x register memory)
Almost right. 14 vs 31. On 32-bit ARM, R13 is stack pointer, and R15 is PC, program counter. 64-bit ARM doesn't have PC mapped to register file anymore.
3. 128-bit floating point
As far as I know, AArch64 does not have 128-bit floating point. Nor would it really be useful except in very rare circumstances.
I am pretty sure that all of the benchmarks showed 64-bit ARM losing to 32-bit, though, by a few percent. The issue is that most code is not able to take advantage of SIMD, and almost all code is not register limited by any stretch, particularly as people tend to write such small functions, and we don't have calling conventions that can try to build register windows (like, "this is an A function that uses this subset of registers while this one is a B function that uses this subset of registers, so if we call a B from an A we don't have to save anything") combined with the top of the stack often being a virtual construct in the CPU anyway (mapped to virtual registers). With the ability for 32-bit ARM to compile stuff to half the code size (due to the Thumb variants), which lets it use half the limited instruction cache space and load faster from disk, it just isn't a very interesting upgrade. Oh: and programs tend to use a lot more memory, as now all of their pointers are twice as big. Some of these downsides are mitigated by the ability to play tricks like tagged pointers (you can't actually use all 64 bits for an address: only 48 or 52 or something are actually wired to the address bus), but except for specialized stuff (where the SIMD and floating point benefits really matter), the only real benefit is "the address space is larger" (a truly useful thing, FWIW, making it much easier to work with large files). (Oh: and it is easier for me to reverse engineer your code due to more useful invariants in the calling conventions ;P. This part makes me really happy.)
I am pretty sure that all of the benchmarks showed 64-bit ARM losing to 32-bit, though, by a few percent.
I think that's true on an RPi with it's super gate constrained, in-order core, but AArch64 was really designed to make OoOE cores with complex prediction a lot easier.
Comments
A few benefits:
1. For DSP / image processing, 64-bit SIMD allows you to operate on twice as many elements as 32-bit SIMD
2. For normal computing, you get 31 64-bit registers instead of 15 32-bit registers (essentially 4x register memory)
3. 128-bit floating point
I think this is very much wrong. You do get more SIMD registers, but both 32-bit and 64-bit ARM have 128 bits wide SIMD registers. Same number of elements per instruction.
Almost right. 14 vs 31. On 32-bit ARM, R13 is stack pointer, and R15 is PC, program counter. 64-bit ARM doesn't have PC mapped to register file anymore.
As far as I know, AArch64 does not have 128-bit floating point. Nor would it really be useful except in very rare circumstances.
64-bit ARM doesn't have PC mapped to register file anymore.
Interesting. Does this have any effect on debugging?
Not really. You can debug i386 code just fine, right? It also doesn't have PC mapped to register file.
I am pretty sure that all of the benchmarks showed 64-bit ARM losing to 32-bit, though, by a few percent. The issue is that most code is not able to take advantage of SIMD, and almost all code is not register limited by any stretch, particularly as people tend to write such small functions, and we don't have calling conventions that can try to build register windows (like, "this is an A function that uses this subset of registers while this one is a B function that uses this subset of registers, so if we call a B from an A we don't have to save anything") combined with the top of the stack often being a virtual construct in the CPU anyway (mapped to virtual registers). With the ability for 32-bit ARM to compile stuff to half the code size (due to the Thumb variants), which lets it use half the limited instruction cache space and load faster from disk, it just isn't a very interesting upgrade. Oh: and programs tend to use a lot more memory, as now all of their pointers are twice as big. Some of these downsides are mitigated by the ability to play tricks like tagged pointers (you can't actually use all 64 bits for an address: only 48 or 52 or something are actually wired to the address bus), but except for specialized stuff (where the SIMD and floating point benefits really matter), the only real benefit is "the address space is larger" (a truly useful thing, FWIW, making it much easier to work with large files). (Oh: and it is easier for me to reverse engineer your code due to more useful invariants in the calling conventions ;P. This part makes me really happy.)
I think that's true on an RPi with it's super gate constrained, in-order core, but AArch64 was really designed to make OoOE cores with complex prediction a lot easier.