Linux x32 ABI Interest Faded In 2013

[phoronix]

Phoronix: Linux x32 ABI Interest Faded In 2013

While the Linux x32 ABI has been talked about since 2011 and there's been mainline Linux kernel support since 2012 and x32 support within other programs has trickled in, there still isn't any widespread interested in this ABI intended for use on 64-bit processors while using 32-bit pointers...

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

[kertoxol]

The right ABI for netbooks, arrived too late.

[brad0]

The right ABI for netbooks, arrived too late.

The netbooks where this mattered were/are using 32-bit processors so you can't use said ABI on those systems. Systems where there are 64-bit processors this isn't an issue. Its work to create an ABI for no real world use and then to have to maintain the compiler/toolchain for something very few people will use.

[DrYak]

The right ABI for netbooks, arrived too late.

And even for the first gen notebooks it would have been that much appropriate.

- Okay, Indeed when a machine has a couple of GiB of RAM, a 4 GiB address of space is mostly enough


But other than that...

- Numerous benchmarks show that the 32 vs 64 bits pointers doesn't impact that much the end performance, except in a few very specific cases. Thus a netbook won't benefit that much from x32.
(I am the impression that the whole "64 bits has a performance impact" is mostly an urban legend, born partly out of the resent of bitter intel fanboys when the precious P4 architecture [32bits only] started to get massively owned by AMD's K8 architecture [64bits too] trying to justify why sticking to 32bits could be better [as such speculation being easy backthen as outside of Linux users, the windows-rest couldn?t really test a 64bits OS], and partly born out of wrong impressions coming from legacy x86 code running much slower on 64bits Itanium [which although 64 bits has a completely different ISA hence the massive performance impact when trying to emulate x86 code on it] )

- x32 is neither compatible with legacy x86 [more registers. that's actually the point], nor with x86_64 [different pointers]. Meaning that one more architecture to be supported for PC platforms running Linux. That isn't that much problematic for Linux distros per se (the move from x86 to x86_64 wasn't that much difficult, thanks to the opensource nature of code used in most Linux distros, and thanks to previous 64bits experience with other 64bits architectures [Sparc 64, Mips 64, etc.] It was almost literally a compile away, give or take a few test to check minor pointer bugs that have managed to get unnoticed until then) but it's problematic for Linux software distributed as closed binary. It was complicated enough to convince software maker to add support to x86_64 (and drag them kicking and screaming to modern architecture), now you add yet *another* arch? Skype is binary only, and x86 only. A Linux x32 netbook would need to be biarch, have an additionnal x86 compatibility layer to get Skype running (just like nowadays a set of "32bits" compatibility libs needs to be installed to get it running on 64bit distros). Flash is also binary only, and backthen only x86 was available with no much opensource alternative. Mozilla on a x32 netbook would need yet another bunch of wrappers, just like the 32-to-64 bits wrapper used on 64bits distros, otherwise, no way to get a x86 plug-in to run from within a x32 or a x86_64 browser (library calling convention aren't the same).

[macpacheco]

Wrong

Most people running those benchmarks that say x32 don't help have a vested interest against it.

It's essentially impossible x32 won't help at least a little.

Pointers are everywhere, and most heavy apps we use a very pointer heavy (GUIs, all virtual machines=JAVA/PHP/Python/Perl/Flash, browsers, e-mail software).

The real issue is developers that maintain those apps don't want one more runtime environment to build and test against. X86_64 took long enough to become fully functional, even with the clear and unquestionable need for it. Given that x32 is a memory downgrade, then it will be very hard to convince every linux package maintainer to adapt (specially those that have some assembly code).

Finally, we need to remember the Microsoft example. Microsoft only cared about performance of the crappy windows when they put out a version that was REALLY SLOW.
Linux developers care more about performance, but they aren't performance nuts.
And all hardware manufacturers have a vested interested in people needing hardware upgrades.
The last statement is why x32 hasn't took off. For the vast majority of Linux work, even a 2012 core i3 is more than fast enough, with 4GB of RAM we're gold.

Only linux users that run thousands of servers have a compelling math that adds up to push x32 (like google). I'm sure they're using it right now and reaping the benefits.

If it were up to me, I'd try to get 100% rid of pure 32bit environment for sometime in 2015, with all mainstream distros moving to a pure 64 bit kernel and a dual x86_64 / x32 dual userland (but without the 32bit compatibility).

But of course, then I woke up from my dream, never gonna happen !

[prodigy_]

Most people running those benchmarks that say x32 don't help have a vested interest against it.

And? Or you mean benchmarks also have a vested interest?

[s_j_newbury]

Gentoo x32

At least on the Gentoo front, a major roadblock is getting complete multi-abi coverage so that it's possible to emerge a system with x32, then use LP64 ABI as appropriate for a given application, or of course x86 where there is only a x86 package availability, with all dependencies resolved automatically.

We were pretty much there with the previous multilib-portage effort, but since that wasn't adopted upstream there's been quite a lot of work modifying ebuilds to integrate support, which is what I've been working on for the last month or so. Since I now have Steam working without any emul-linux-x86 binaries, I'm going to start pushing my changes out to ebuild maintainers, so hopefully this will be landing soon. Once that's done I'm going to have another attempt at bringing up x32 as a fully supported ABI, I probably need to have another look at llvm/clang...

[jokeyrhyme]

implications for 64-bit ARM CPUs? Android?

Does anyone know if the strategy for x32 (use 64-bit features within 32-bit limits) has any value outside of x86? I'm specifically curious about the recently released 64-bit ARM ISA and its emulation of the original 32-bit ISA.

The primary advantage for x32 (unless I'm mistaken) was lower RAM usage. This would seem to be especially important for the embedded devices that typify ARM usage. And even more important for garbage-collected environments like Android.

[energyman]

x32 was 'invented' by Intel because ATOM sucks with 64bit pointers. That is all. They build a suckfest of a CPU and to save the day they splintered the x86 market even more.

Nice move intel, you idiots.

[macpacheco]

And? Or you mean benchmarks also have a vested interest?

There's no magic about how x32 works exactly.
The only way that x32 could be slower than regular 32bit or x86_64 is some system calls that require conversion of the pointers passed.
Plus this set of pure 32bit, 64bit data/32bit pointer and pure 64bit isn't anything new.
When it's all said and done, you must get some performance improvement, except for some very rare cases that uses almost no pointers.
You don't need benchmarks to show that in average there will be 5-10% performance gains.
I see way too many people criticize x32, but the way they word their messages, it looks like they don't really understand every (positive) impact x32 will have on performance.
They try to frame x32 as only useful for embedded systems where RAM might be limited, showing they don't really understand (and don't care to understand it correctly).
People forget that the main issue isn't saving RAM, but improving cache hits by reducing the size of data structures, reducing per function stack usage (also to improve cache hits), and reduce RAM bandwidth usage.
If this x32 thing isn't so great, then please get just one hardcore linux kernel developer or some other developer known to care about performance to say x32 isn't a big deal, please.
I'm not a kernel developer, but I'm a performance person that started using computers back in the 8 bit times, and learned assembly before C, while (I'm almost sure) most people saying: "this isn't a big deal, prove me it's useful" are much younger guys that are used to be lazy about performance. Sorry about the prejudice, I would like people give their technical credentials before criticizing.
I have 30 years of computer experience, how much do you have ?
Depending on your experience you just know what will work, what won't, and what needs testing. x32 is one of those cases that I know it will work (be worth it). And I'm yet to see a LOGICAL explanation why it might not work (not be worth it).