Hacker News Reader

Comment by markcerqueira | Hacker News Reader

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

View on HN

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://lwn.net/Articles/456731/

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)

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.

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.

Improved security with care for performance, little things like SGX, MPX, IO and GPU DMA in hypervisors, for example.

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.

Parent stated:

> In practice only two architectures matter: x86 and ARM.

So I replied about x86, because that is the architecture I know best.

Assuming the most performance intensive tasks most users do is browse the web, it's probably a win. Webkit's garbage collector is conservative-- it scans all memory looking for possible pointers-- so it runs more efficiently on 64-bit architectures where valid pointers are unlikely to randomly occur. Lots of JIT tricks like tagged pointers really work best on 64-bit architectures. https://webkit.org/blog/7122/introducing-riptide-webkits-ret...

It's not just extra registers and address space. ARM64 is a large-scale restructuring to better enable modern processor design, including things like removing barrel shifting on every instruction (expensive and not very useful) and removing predication on every instruction (expensive and makes OoO machinery slower). http://stackoverflow.com/a/26841196

I believe there are actually some cool things they do with the extra space in the Objective-C runtime. It's been a while so I may be mistaken but I think they store the reference count in the pointer to avoid a lookup to a separate table. There might also be some trickery in storing NSNumber values in the pointer itself as well.

EDIT: Grammar

As the 64-bit CPUs used on the iPhone actually only have 33-bits of address space (undermining the benefits of having more address space ;P), Apple does use the extra space in a pointer to store "tagged" values in some cases, but for the most part this can be seen as a "mitigation": as the size of a pointer is now 64-bits, and as the alignment of a lot of things is now 64-bits because of that, processes are larger and heavier than on 32-bit systems, and thereby require more memory bandwidth. Sharing some of the bits of a pointer is essentially required to win back this lost performance. (Another great option is a 32-bit ABI using the 64-bit instruction set, as with x32 on Intel, but Apple did not go that direction.)

>higher cache miss rate from the larger code and data sizes.

Can you explain how these are related? What do you mean by "larger code"? I'm assuming you're talking about the binaries, rather than actual code.

I'd agree with you on the large data size but I really don't think 32->64 bit increase will make much difference overall unless someone is using a lot of existing numerical data. Most of the data is taken up by multimedia resources and this won't really be affected by the architecture.

More registers are always good, unless you have a terrible compiler. And since Apple uses LLVM a lot, and actually takes care of the compiler backend. I don't really see caching problems. AFAIK there will be more registers to store data in so caches will actually be used less than usual.

Pointer size doubles, so any data structure (linked list, tree, etc, etc) which uses raw pointers directly will need more memory to store the same items.

Normal way of negating this increase is to use uint32_t offset items into a master array of the items the pointers represent, which reduces the size again and has a side benefit of possibly making the items more coherent (localised) in memory.

On x86, it's just the extra registers, and indeed 32-bit can be faster. But AArch64 is essentially a completely different ISA from AArch32. Here's an old benchmark from Apple's first 64-bit CPU that shows a significant improvement on benchmarks in 64-bit versus 32-bit mode on the same device:

http://www.anandtech.com/show/7335/the-iphone-5s-review/4

Of course, this may be an idiosyncrasy of that processor implementation, or it may not generalize well to real applications which tend to stress the instruction cache more...

Being able to rely on at least SSE2 is a big win for 64-bit on x86.

Technically you could use 32-bit addresses on a 64-bit processor and not have your data be any bigger, but most languages don't offer a good way to do this (IIRC the HotSpot JVM's UseCompressedOops option does something along these lines).

This is actually implemented on Linux/glibc: https://en.wikipedia.org/wiki/X32_ABI

You can compile C/C++ programs using this ABI, and get all 64-bit benefits without 64-bit pointers.

> So for all practical purposes: YES, the 64-bit transition has actual real benefits to end users besides the larger address space

This is technically true, but it's a very bland statement vs "64-bit yields end-user performance improvements" or even "64-bit is a net positive".

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.

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.

128-bit NEON has been available on 32-bit ARM for a long time, since Cortex-A8 (2005) or so.

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

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.

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.

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.

Reply on news.ycombinator.com