That's not entirely true. Under Linux, with the x32 ABI (see https://lwn.net/Articles/456731/) you have access to the entire register file, but still use 32-bit pointers.
In many ways, it combines the advantages of 32- and 64-bit mode code.
That's not entirely true. Under Linux, with the x32 ABI (see https://lwn.net/Articles/456731/) you have access to the entire register file, but still use 32-bit pointers.
In many ways, it combines the advantages of 32- and 64-bit mode code.
That said it can be useful for certain loads where you aren't consuming large amounts of memory but are doing lots of calculations.
[1] http://stackoverflow.com/questions/16841382/what-is-the-perf...
Ubuntu has some x32 packages available for their standard 64 bit distribution, but the selection is limited.
In theory, x32 should still be faster because the code gets to use all the other x64 features, like a larger register set and so on. I've no idea how big a difference that actually would make though.
The theoretical possibility for speedup is exactly why I asked. The x32 website has benchmarks where it's as fast as i386 and 40% faster than amd64 on pointers or as fast as amd64 and 40% faster than i386 on 64 bit math, but what's missing to really justify x32 is some "20% better than either" case.
Another fun tidbit -- the debugger is blissfully unaware that the CPU and compiler are conspiring to do this. If you debug such a program, it will work fine. If you set a breakpoint on the instruction in question and simply continue, the entire program freaks out because the debugger just chopped off the high 32 bits of whatever it touched. I found that amusing when hitting it while debugging an issue. (Sad face)
In general most tools freak out if they encounter this because they were built under the assumption this was impossible.