The x32 system call ABI [LWN.net]

The x32 system call ABI

Posted Sep 1, 2011 23:00 UTC (Thu) by dlang (guest, #313)
In reply to: The x32 system call ABI by gerdesj
Parent article: The x32 system call ABI

depending on the application, the fact that pointers and memory addresses change from 32 bits to 64 bits can actually slow the system significantly.

the larger footprint uses more CPU cache, making the system spend more time waiting for the cache to be updated from memory.

this is why many of the chips that have both 32 bit and 64 bit modes tend to run 64 bit kernels with 32 bit userspace, for programs that don't need to address more than 4G of ram, the overhead of the larger data objects results in a slowdown

x86/AMD64 is pretty much unique in the fact that 64 bit mode doesn't just extend the registers to 64 bits, it also gives you twice as many registers to work with. Since the x86 platform has far fewer registers than more modern designs, the availability of more registers means that far more things can happen in the CPU itself, without having to save and load values out to the cache (or worse yet, to RAM) in a constant shuffle to get register space for the things that need it. x86 systems spend a HUGE amount of time doing this register shuffle.

the idea behind the x32 architecture is to be able to take advantage of these extra registers (which almost always result in improved performance) without having to pay the overhead of larger pointers to memory.

the fact that many 32 bit applications that are nto 64 bit clean can be made to run in this mode is pure gravy, and if the time change takes place, this may be sacraficed in order to get a better long-term x32 architecture.

to post comments

That way lies madness

Posted Sep 2, 2011 5:35 UTC (Fri) by eru (subscriber, #2753) [Link] (13 responses)

I can see the reasoning, but still I feel the ideal is very bad. It reminds me too much of the "memory models" of MS-DOS, 16-bit Xenix and 16-bit OS/2, and the problems associated to having then separate library versions of each, and slightly different requirements and capacities of programs depending on how they were compiled. Been there, and did not like it. Please don't bring this mess to Linux!

Having more modes just means more available ways for the programmer to screw things up, and more possibilities for low-level bugs and security holes in the kernel and C library. The now-existing 32-bit mode in x86_64 is justifiable for supporting legacy binaries, but other memory models will just complicate things with very little gain.

That way lies madness

Posted Sep 2, 2011 14:41 UTC (Fri) by nix (subscriber, #2304) [Link] (12 responses)

Please don't bring this mess to Linux!

Linux has had 'this mess' since the days of SPARC64 in the 90s, and now with x86-64 and x86-32, biarchy is downright common. The linker and dynamic linker know about it, and you cannot accidentally link against the wrong library. Biarch packaging problems have largely been weeded out by the ubiquity of x86-64.

That way lies madness

Posted Sep 2, 2011 19:02 UTC (Fri) by dlang (guest, #313) [Link] (11 responses)

I know hat Sparc and PowerPC both have this sort of 32/64 split.

and as far as I have seen, almost all distros for those chips ship 64 bit kernels with 32 bit userspace because 32 bit binaries are faster to run than 64 bit ones (due to the more compact code and memory addresses), as long as you can live in 4G of address space as an application.

there are actually very few cases where a single application needs to address more than 4G of address space, and in many, if not most of those cases there are real advantages to just running multiple processes rather than a single giant process. so this works very well in the real world.

That way lies madness

Posted Sep 2, 2011 22:36 UTC (Fri) by martinfick (subscriber, #4455) [Link] (7 responses)

> there are actually very few cases where a single application needs to address more than 4G of address space,

I guess you think java applications are few. :)

That way lies madness

Posted Sep 2, 2011 22:47 UTC (Fri) by dlang (guest, #313) [Link] (6 responses)

yes, the number of Java applications where a single application needs to address more than 4G of memory are few.

remember that visualization is supposed to be the wave of the future, especially for things in datacenters. part of the way this works is that you slice up the memory available on a server to allocate it between many more small servers. most such servers end up with less than 4G per virtual server and what we are talking about for x32 is 4G per _application_ (not counting OS buffering, kernel allocations, or any other overhead) this is a lot more elbow room.

not every application can fit in 4G, but when you really look at it, a surprising number of them will.

and pointer-heavy things like Java are especially likely to benifit from the smaller pointers of x32

That way lies madness

Posted Sep 5, 2011 7:48 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Java actually benefits so much, that Oracle JVM actually implements userspace pointer compression!

http://wikis.sun.com/display/HotSpotInternals/CompressedOops and
http://blog.juma.me.uk/tag/compressed-oops/

That way lies madness

Posted Sep 5, 2011 22:38 UTC (Mon) by intgr (subscriber, #39733) [Link] (4 responses)

> and pointer-heavy things like Java are especially likely to benifit from
> the smaller pointers of x32

Offtopic, but interesting: 64-bit Java already offers the -XX:+UseCompressedOops option which turns on pointer compression. By dropping 3 bits from the least significant end of the address, it can address 32GB of memory using 32-bit pointer fields.

That way lies madness

Posted Sep 6, 2011 14:35 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Userspace pointer compression has its own costs. In my tests it often performs worse than non-compressed version.

That way lies madness

Posted Apr 2, 2012 14:30 UTC (Mon) by Richard_J_Neill (subscriber, #23093) [Link] (2 responses)

This is quite a clever trick. If I understand rightly, what Java is doing is giving up byte-addressability, in favour of more address space. I.e. you can't create a pointer to a byte/char any more; the smallest data-type then becomes an int, and strings have to contain 4*n bytes. Given that x86 accesses memory 32-bits at a time anyway, this is a fairly natural thing to do.

That way lies madness

Posted Apr 3, 2012 20:49 UTC (Tue) by ibukanov (subscriber, #3942) [Link] (1 responses)

> Given that x86 accesses memory 32-bits at a time anyway,

On modern CPU memory is addressed internally by cache lines that are typically 16-32-64 bytes in size. On x86 the byte access is just as fast as 32-bit access. Moreover, misaligned access to 32-bit values is allowed and is not costly as long as the variable does not cross the cache line boundary.

That way lies madness

Posted May 21, 2012 15:08 UTC (Mon) by mikemol (guest, #83507) [Link]

For basic instructions, yes. Take a look at the SSE instructions; while there are unaligned and aligned versions for several, the aligned versions will carry better performance.

That way lies madness

Posted Sep 3, 2011 11:50 UTC (Sat) by raven667 (subscriber, #5198) [Link] (2 responses)

I kind of wish that the Linux distros took that approach when transitioning to x86_64, I am of the opinion that the transition would have been a lot smoother especially for desktops had that been the case.

That way lies madness

Posted Sep 3, 2011 17:12 UTC (Sat) by dlang (guest, #313) [Link] (1 responses)

there were two big factors that cause distros to go the direction they did for AMD64

1. especially early on there were problems with the compatibility mode causing occasional 'strange' errors when running 32 bit userspace on a 64 bit kernel.

2. the added registers of 64 bit mode significantly improve the performance of 64 bit code vs 32 bit code, in almost every case even when you take into account the extra overhead of the larger pointers.

That way lies madness

Posted Sep 6, 2011 3:30 UTC (Tue) by butlerm (guest, #13312) [Link]

Isn't this likely to be superior enough to motivate desktop distributions to switch to an x32 user space with a 64 bit kernel, with x86-64 libraries as extensions for those applications that actually benefit from a large address space?