x32 Support For Linux Kernel Called In For Review

[phoronix]

Phoronix: x32 Support For Linux Kernel Called In For Review

The x32 effort, an undertaking to provide a native 32-bit ABI for x86_64 on Linux, is finally moving closer to fruition. Peter Anvin has published the set of x32 patches for the Linux kernel that are now up for review and comments...

http://www.phoronix.com/vr.php?view=MTA1OTY

[Azpegath]

This sounds great! I assume (and hope it doesn't make an ass out of me) that this means that native 32-bit applications can run on a 64-bit system without problems (or libraries built specifically for it, like nspluginwrapper). Or is that hoping for too much?

[log0]

You will have to compile the applications to target the x32 abi. But the possible 30% speedup compared to x86-64 sounds interesting.

[werfu]

You will have to compile the applications to target the x32 abi. But the possible 30% speedup compared to x86-64 sounds interesting.

I'm wondering how this will change Linux ecosystem. Likely that most application always using less than 4gb of memory will always be compiled using the x86 ABI. But isn't it reducing the 64bit usefullness?

[chris200x9]

I'm wondering how this will change Linux ecosystem. Likely that most application always using less than 4gb of memory will always be compiled using the x86 ABI. But isn't it reducing the 64bit usefullness?

I don't think it will change much, the OS is still 64-bit and can address more than 4 gb and you can compile things like gimp that may need more than 4 gb of ram in 64-bit. Why though do I need a 64-bit pidgin?

edit: I see what your saying "what if you don't know it'll use more or less than 4 gb, isn't this the advantage of a 64-bit sytem?"

true, I think if you have any kind of inkling it might use 4 gb it's best to build 64-bit.

[Veerappan]

I don't think it will change much, the OS is still 64-bit and can address more than 4 gb and you can compile things like gimp that may need more than 4 gb of ram in 64-bit. Why though do I need a 64-bit pidgin?

edit: I see what your saying "what if you don't know it'll use more or less than 4 gb, isn't this the advantage of a 64-bit sytem?"

true, I think if you have any kind of inkling it might use 4 gb it's best to build 64-bit.

What you said... Pretty sure that this will be most useful for applications which will never need >= 4GB of memory, but can benefit from the increased register count of the x86_64 ISA.

This might also be useful when porting some applications from 32-bit to 64-bit where the original developer was using some really messed up pointer arithmatic. The pointer manipulation should be fixed anyway, but this might help out as a bridge.

[Kano]

You should not think that the 08/15 Linux user will benefit from it. The main purpose is to optimize for specific benchmarks. Some are fine with 64 bit binaries, others are faster with 32 bit, so in order to get the max speed he wants to combine the best results. Thats why he uses SPEC benchmark results. It has definitely nothing to do if you use pidgin as 32 or 64 bit binary. It is just to squeeze out the max performance for time critical apps.

[XorEaxEax]

The biggest _performance_ increase from going 64bit came not from more addressable memory but from the addition of 8 more cpu registers. CPU registers are the fastest place in the computer in which to perform operations on data (much faster than cpu caches) and therefore it's extremely beneficial for 64-bit cpu's to have these 8 extra registers when doing cpu intensive stuff (particularly since the 32-bit cpu only had 8 to begin with).

The drawback is that the code size gets larger in 64-bit mode due to address references being 64-bit instead of 32-bit, which leads to the cache filling up faster which in turn may lead to less performant code. But even so, 64-bit code usually wins out over 32-bit code with a wide margin due to those extra 8 registers.

Now enter x32 ABI, in this mode you can use the extra 8 registers for that increased performance while still only using 32-bit address references which means more code can fit into the cache which may lead to extra performance. Also, as the code uses 32-bit addressing the resulting binaries are smaller (iirc typically a 64-bit system is ~15% larger than an equivalent 32-bit system), so if you don't need 64-bit addressing ( > 4g ram ) then x32 is pretty much best of both worlds.

[curaga]

Unless you'll be running a pure x32 system, there's going to be two sets of libs competing for ram and cache, the native 64bit and the x32 ones. Assuming any multiprocessing machine, is this not a downside?

Though if a server mainly does one thing, this wouldn't matter.

[smitty3268]

CPU registers are the fastest place in the computer in which to perform operations on data (much faster than cpu caches) and therefore it's extremely beneficial for 64-bit cpu's to have these 8 extra registers when doing cpu intensive stuff (particularly since the 32-bit cpu only had 8 to begin with).

Just to clarify, registers are the ONLY places that you can perform operations on data. CPU caches exist so that storing/loading data into the registers is faster than going out to main memory (which in turn is faster than acessing a hdd). Having more registers means you need fewer load/store operations and can leave the data you need directly in the cpu.

Also, besides doubling the number of registers it also doubles their size. Some code, like pointers, takes up the whole new 64bit size, but for really critical code you can now try and use 1 register for 2 32bit components, giving you up to 4 times the number of registers.