| |||||||||||||
That way lies madnessThat way lies madnessPosted Sep 2, 2011 14:41 UTC (Fri) by nix (subscriber, #2304)In reply to: That way lies madness by eru Parent article: The x32 system call ABI
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.
(Log in to post comments)
That way lies madness Posted Sep 2, 2011 19:02 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
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]
> 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 (✭ supporter ✭, #313) [Link]
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
That way lies madness Posted Sep 5, 2011 22:38 UTC (Mon) by intgr (subscriber, #39733) [Link]
> 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]
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]
> 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 (subscriber, #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]
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 (✭ supporter ✭, #313) [Link]
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 (subscriber, #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?
|
|||||||||||||