3 ms·

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 SIM

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

by pohl 13y ago

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.