x32 ABI

Grinch · 2012-04-15 12:17:33

Not sure if this is the correct section but it seemed appropriate, in kernel 3.4 we will see the introduction of the new x32 ABI. What this ABI offers is the possibility of compiling programs to use 32-bit addressing while still enjoying the enhanced instruction set of x64.

64-bit practically always beats 32-bit in performance due to having twice the number of registers available, however there is a drawback to 64-bit in terms of performance and that's because 64-bit addressing makes the code larger which in turn means that less code fits into the cpu caches. x32 brings you the best of both worlds by using 32-bit addressing which keeps the code smaller while still being able to utilize the cpu enhancements of 64-bit mode, with one caveat: programs (processes) are only able to address 4gb of memory. This is a 'per process' limitation though, so if you have 16gb ram it doesn't mean all processes need to share the same 4gb space (unless I have misunderstood what I've read).

So should we want to use it? Well benchmarks apparently showed ~15% performance increase on cpu intensive programs when compiled with x32 compared to x64, also overall memory footprint will drop given that the code gets smaller.

Now in order to use this ABI programs need to be compiled against it, gcc already supports this with -mx32 but obviously it's pointless unless you have a kernel which supports this ABI (3.4) and atleast having x32 versions of the standard system libraries.

Now I have no idea of this will be officially supported by Arch (x86_x32 ?) but I personally would like it as I have every intention to try it out once 3.4 hits the streets. Anyway I just thought I'd write a bit about what I've read concerning it and perhaps spawn some interesting discussions, take care!

Pierre · 2012-04-15 14:26:04

It's very unlikely that we will add this as a third x86 architecture to Arch (Doesn't mean some people could do it). There are also only benefits for some edge cases; overall you are way better off with pure x86_64.

swiftgeek · 2012-05-12 16:02:21

This isn't about edge cases — the most important feature of x32 is reduced memory footprint.
And 4-8GiB limit for capacity of all RAM modules is quite common — mostly because faulty of written (or copy&pasted) ram init code in bios/uefi.

Pure x86_64 is better only with edge case when You have enough ram space to do anything… otherwise you will end up in swap…

Last edited by swiftgeek (2012-05-12 16:06:13)

puuff · 2012-05-12 17:29:43

This is precisely what I have wanted for a long time. Each time I install a system I always ask myself the question where all the memory go. It's not that I don't have enough of computer memory but I don't like wasting memory when there's no point in doing it.

ZekeSulastin · 2012-05-12 18:22:46

I like how both of the posters today bleat about RAM use like it's the actual issue the OP brought up that was solved. Hint: it's not. Second hint: if you're running into RAM issues on a 64-bit system, I highly doubt this ABI will fix your problem (also you should go look up what an edge case is - typical operating parameters do not an edge case make).

I imagine the first major distro to support this ABI will be Gentoo via a use flag of some sort - it should be interesting to see what, if any, performance improvements they see in a typical workload.

Last edited by ZekeSulastin (2012-05-12 18:23:43)

Allan · 2012-05-12 21:48:37

ZekeSulastin wrote:

I imagine the first major distro to support this ABI will be Gentoo via a use flag of some sort - it should be interesting to see what, if any, performance improvements they see in a typical workload.

Look at their glibc ebuild...

[[ ${CHOST} == x86_64* ]] && has x32 $(get_all_abis) \
 	|| GLIBC_PATCH_EXCLUDE+=" 1200_all_glibc-${PV}-x32.patch"

I have always wondered why a distro would pick this up given the main people working on it seem to indicate they think it useful for closed/embedded systems (http://linuxplumbersconf.net/2011/ocw//system/presentations/531/original/x32-LPC-2011-0906.pptx - page 10...)

Grinch · 2012-05-13 07:38:24

Allan wrote:

I have always wondered why a distro would pick this up given the main people working on it seem to indicate they think it useful for closed/embedded systems (http://linuxplumbersconf.net/2011/ocw//system/presentations/531/original/x32-LPC-2011-0906.pptx - page 10...)

Well, it seems Ubuntu is considering it http://summit.ubuntu.com/uds-q/meeting/ … -planning/

Personally I don't see a decrease in memory usage as the main attraction (although it could potentially use even less RAM than standard 32-bit code which is quite nice) but rather the benchmarks speaking of ~15% performance increase over 64bit due to more code fitting into the cpu caches.

Of course limiting programs to 4gb ram (per process, not system in total) is a drawback but I have lots of cpu intensive stuff I'm using regularly where a possible 15% performance increase would be quite a boon. Also, if you have 4gb or less and a 64bit cpu then x32 is pure win, less ram usage and better performance.

Obviously x32 wasn't developed with the desktop in mind (is anything kernel related?) but that doesn't mean we don't get to enjoy it's benefits should we want to.

Cdh · 2012-05-13 11:48:54

Will the kernel option be enabled and the tools to actually build applications for x32 be in the main repositories?

The mainline kernel from AUR/the unofficial repository tries to use the "old" arch config until a new one is available and it seems to be disabled by default up to now:

 % zgrep CONFIG_X86_X32 /proc/config.gz
# CONFIG_X86_X32 is not set

As i understand it it wouldn't be an additional architecture to i686 and x86_64 but rather one could provide additional versions for popular software in the repositories:
For example "firefox" and "firefox-x32".
Or create add a repository like multilib-x32 or something.

Barrucadu · 2012-05-13 13:05:35

I don't see why the stock Arch kernel shouldn't support the ABI, however I agree that having x32 packages in addition to the current two architectures would be too much work for too little gain.

Grinch · 2012-05-15 06:42:44

Well not enabling x32 in the kernel would be crazy, supporting it however is another question entirely. To build x32 programs you would need a compiler which supports it and this we have, gcc 4.7 can compile x32 code by simply adding the -mx32 flag.

But you also need libraries compiled as x32, and unless you have extremely meager needs you won't get away with just glibc/libstdc++ etc but rather the tons of dependancies most applications rely on these days. Also unless you decide to go x32 only this means you will have to keep both x64 and x32 versions of lots of libraries or alternatively choose to build applications for one of these ABI's statically.

For me it boils down to wether or not the potential speed increase as showed in benchmarks is actually more of a generality rather than an anomaly, if x32 offers ~15% increase in lots of cpu intensive code then I will try hard to get my system up and running using x32 or at the very least have my cpu intensive applications compiled and running as x32.

kokoko3k · 2012-07-01 14:41:24

@Grinch: Are you sure you need all the linked libraries to be built with -mx32?

Glibc 2.16 was just released with support for X32 ABI:
http://www.gnu.org/software/libc/

Grinch · 2012-07-01 14:59:39

Yes, as soon as glibc 2.16 hits the official arch repos all the puzzle-pieces required (I think!) to start building x32 binaries are present. Likely I will have to recompile the kernel aswell as Gcc as unless I'm mistaken the official Arch packages are not compiled with x32 support, same will most likely be true for glibc 2.16 shipped with Arch.

kokoko3k wrote:

@Grinch: Are you sure you need all the linked libraries to be built with -mx32?

Yes I'm quite certain of that, however a solution other than choosing x32 only or keeping two sets of libraries (x32, x86_64) would be to statically link x32 libraries with x32 binaries needing them rather than installing the x32 libraries in the system to be linked dynamically. Personally I'm mostly interested in trying x32 on applications where it's potential performance increases (and to a lesser extent smaller memory footprint) may have an impact than perhaps system-wide (although I'm interested in that aswell).

I will be playing around with this during the summer (always some rainy days here in sweden) and if you're interested I'll report back with my results.

Trilby · 2012-07-01 15:46:42

I ask out of pure curiosity, not skepticism, but which single process(es) ever use 4gb memory?

Fackamato · 2012-07-01 15:50:26

Trilby wrote:

I ask out of pure curiosity, not skepticism, but which single process(es) ever use 4gb memory?

If you're refering to performance stuff, it's the registers as well.

kokoko3k · 2012-07-01 17:13:51

Trilby wrote:

I ask out of pure curiosity, not skepticism, but which single process(es) ever use 4gb memory?

I think graphic tools like gimp or imagemagick or blender...

@Grinch:
I'd be very interested on your results as i'm on 32bit+pae mainly because of the memory footprint.

...And as far as i know, X32 'addressable memory' restrictions applies to pae too, but they didn't gave me any trouble so far...

Last edited by kokoko3k (2012-07-01 17:17:16)

Grinch · 2012-07-01 22:31:15

kokoko3k wrote:

I'd be very interested on your results as i'm on 32bit+pae mainly because of the memory footprint.

Well for x32's lower memory usage as opposed to x86_64 I believe you'd want to use x32 across the entire system for it to have a real impact. It should use the same amount or slightly less ram than a equivalent standard 32-bit system, so if you are already running a 32-bit system x32 will not use less ram (well, perhaps a little less due to not having as much push/pop instructions in it's code due to having more registers) except for the kernel which is 64-bit, I assume the usual ~20% difference in code size between 32-bit and 64-bit code applies here aswell.

Applications, particularly cpu-intensive stuff should run noticeably faster using x32 vs 32-bit, just as x86_64 runs faster than 32-bit, and as benchmarks have shown x32 code often runs faster than equivalent x86_64 code, sometimes by a wide margin.

As I mentioned above, the kernel however is the 'standard' 64-bit kernel with builtin x32 abi support and thus have larger memory footprint than a standard 32-bit kernel. The upside with using the standard 64-bit kernel is that the x32 4gb limit is 'per process', so if you have 8gb ram and x32 two separate memory hungry processes could theoretically get 4gb ram each (well, obviously minus system resource usage).

Basically, if you are running a system with 4gb or less on a 64-bit cpu then x32 is technically the best choice, it will use less memory than x86_64 and judging by benchmarks also have better performance. Practically it's another thing entirely, as there's no officially supported x32 arch which means you would have to compile your own system and all library dependancies you require by hand.

Once I (hopefully!) get x32 up and running I'll get back with some results, I'll probably wait until glibc 2.16 hits core before I start messing around though.

falconindy · 2012-07-01 23:34:37

Required reading before too much FUD spreads here...

http://blog.flameeyes.eu/2012/06/is-x32 … -answer-no
http://blog.flameeyes.eu/2012/06/debunking-x32-myths
http://blog.flameeyes.eu/2012/06/last-f … -about-x32

Grinch · 2012-07-02 02:39:13

falconindy wrote:

Required reading before too much FUD spreads here...

What would be the FUD spread here? Fear, uncertainty, doubt... ? Please point it out.

Also the blog posts by flameeyes, I've read them and they contain nothing but his opinion/speculation. What 'myths' he debunked I don't know, because you debunk something with facts, not speculation, and apart from the benchmarks we've seen from the Intel developers speculation is pretty much all we have.

Also for some responses to his blog posts regarding x32 which offer a wider spectrum of opinions and speculations than just flameeyes, this lwn thread is a worthwhile read: https://lwn.net/Articles/503412/

Flameeyes is no fool, but neither are the Intel employees who where paid to create this ABI, if there was no worthwhile gain from it I find it extremely unlikely it would ever had been implemented in Linux, GCC, glibc (which was not exactly trivial) and certainly not funded to finalization by Intel to begin with. They have offered benchmarks, synthetic as they may be, Flameeyes have offered speculation.

Now, memory-wise we already know that two equivalent systems, one 32-bit and one 64-bit means the 64-bit will use ~20% more ram. I've just recently confirmed this with Arch Linux running in VirtualBox, one 32-bit, one 64-bit, identical setups software-wise. So the ram advantage of 32-bit/x32 over 64-bit is I dare say undisputed. The question is (for me atleast) if the performance gains shown by some of the synthetic benchmarks also holds relevance in real-world cpu-bound programs and this is what I want to see by trying out x32 for myself once all the ncecessary components are available under Arch.

Also, as I've stated previously in this thread, I do not believe nor expect Arch to support x32. I have also no plans of building an entire x32 system, I'm only interested in the potential increase in performance it may bring to certain cpu bound software and my personal interest in code optimization in general.

Mr.Elendig · 2012-07-03 13:50:08

glibc 2.16 is out with x32 abi

Last edited by Mr.Elendig (2012-07-03 13:51:56)

fantix · 2012-07-23 16:15:34

Pierre wrote:

Doesn't mean some people could do it

I cannot wait until "some people" show up to try it out in Arch I've uploaded a few x32 AURs:

~~linux-x32: https://aur.archlinux.org/packages.php?ID=61029~~ <-- not needed any more if you have official kernel >= 3.5.4-1
glibc-x32-seed: https://aur.archlinux.org/packages.php?ID=61141
gcc-x32-seed: https://aur.archlinux.org/packages.php?ID=61142
libx32-glibc: https://aur.archlinux.org/packages.php?ID=61143
gcc-multilib-x32: https://aur.archlinux.org/packages.php?ID=61158

Please feel free to comment

This is how it works in general:

http://sourceware.org/glibc/wiki/x32

FIRST INSTALL:
Note, the first build from scratch is a bit tricky. If you don't want to do it all by yourself, you can get my binary packages from archlinuxcn.org repo (repo desc in Chinese)

1. ~~Install linux-x32 (kernel and headers), boot into it.~~<-- not needed any more if you have official kernel >= 3.5.4-1
2. Install the two seed packages: glibc-x32-seed and gcc-x32-seed. (It's been a long while since I last time used them - please report if they doesn't work)
3. Build and install libx32-glibc - it will conflict with glibc-x32-seed, remove the latter one.
4. Build and install gcc-multilib-x32. It will conflict with gcc, gcc-multilib and gcc-x32-seed - remove them all. (gcc-multilib-x32 works for x86, x86_64 and x86_x32)

Last edited by fantix (2012-10-29 10:39:42)

Grinch · 2012-07-25 03:42:03

Awesome fantix, I go on vacation today (yay!) and had planned to spend some (of the inevitably) rainy days to get a x32 toolchain up and running to do some benchmarking but you've saved me alot of work, THANK YOU! I'll be sure to try this out and get back to you if I encounter any problems!

fantix · 2012-07-25 06:02:13

Grinch wrote:

Awesome fantix, I go on vacation today (yay!) and had planned to spend some (of the inevitably) rainy days to get a x32 toolchain up and running to do some benchmarking but you've saved me alot of work, THANK YOU! I'll be sure to try this out and get back to you if I encounter any problems!

My pleasure to contribute Your comments are greatly welcome.

I'm trying to submit the binary package to repo.archlinuxcn.org (https://bbs.archlinuxcn.org/viewtopic.php?id=798, Chinese), so that people don't have to compile every time.

unma · 2012-08-09 10:54:25

fantix wrote:

I'm trying to submit the binary package to repo.archlinuxcn.org (https://bbs.archlinuxcn.org/viewtopic.php?id=798, Chinese), so that people don't have to compile every time.

Was there any progress made?

fantix · 2012-08-10 10:18:22

unma wrote:

fantix wrote:
I'm trying to submit the binary package to repo.archlinuxcn.org (https://bbs.archlinuxcn.org/viewtopic.php?id=798, Chinese), so that people don't have to compile every time.
Was there any progress made?

Made a request ... will update here when approved

fantix · 2012-08-17 03:23:17

unma wrote:

fantix wrote:
I'm trying to submit the binary package to repo.archlinuxcn.org (https://bbs.archlinuxcn.org/viewtopic.php?id=798, Chinese), so that people don't have to compile every time.
Was there any progress made?

Packages are uploaded, listed in this page. This repo is also listed here.

GCC was compiled without Ada because even with backported r184859 it still fails.

Last edited by fantix (2012-10-26 02:37:07)

Arch Linux

#1 2012-04-15 12:17:33

x32 ABI

#2 2012-04-15 14:26:04

Re: x32 ABI

#3 2012-05-12 16:02:21

Re: x32 ABI

#4 2012-05-12 17:29:43

Re: x32 ABI

#5 2012-05-12 18:22:46

Re: x32 ABI

#6 2012-05-12 21:48:37

Re: x32 ABI

#7 2012-05-13 07:38:24

Re: x32 ABI

#8 2012-05-13 11:48:54

Re: x32 ABI

#9 2012-05-13 13:05:35

Re: x32 ABI

#10 2012-05-15 06:42:44

Re: x32 ABI

#11 2012-07-01 14:41:24

Re: x32 ABI

#12 2012-07-01 14:59:39

Re: x32 ABI

#13 2012-07-01 15:46:42

Re: x32 ABI

#14 2012-07-01 15:50:26

Re: x32 ABI

#15 2012-07-01 17:13:51

Re: x32 ABI

#16 2012-07-01 22:31:15

Re: x32 ABI

#17 2012-07-01 23:34:37

Re: x32 ABI

#18 2012-07-02 02:39:13

Re: x32 ABI

#19 2012-07-03 13:50:08

Re: x32 ABI

#20 2012-07-23 16:15:34

Re: x32 ABI

#21 2012-07-25 03:42:03

Re: x32 ABI

#22 2012-07-25 06:02:13

Re: x32 ABI

#23 2012-08-09 10:54:25

Re: x32 ABI

#24 2012-08-10 10:18:22

Re: x32 ABI

#25 2012-08-17 03:23:17

Re: x32 ABI

Board footer