Page 1 of 3 123 LastLast
Results 1 to 10 of 22

Thread: Linux x32 ABI Interest Faded In 2013

  1. #1
    Join Date
    Jan 2007
    Posts
    14,646

    Default Linux x32 ABI Interest Faded In 2013

    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

  2. #2
    Join Date
    Dec 2012
    Posts
    19

    Default

    The right ABI for netbooks, arrived too late.

  3. #3
    Join Date
    May 2012
    Posts
    116

    Default

    Quote Originally Posted by kertoxol View Post
    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.

  4. #4
    Join Date
    Apr 2008
    Posts
    158

    Default

    Quote Originally Posted by kertoxol View Post
    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).

  5. #5
    Join Date
    Dec 2013
    Posts
    17

    Default 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 !

  6. #6
    Join Date
    Mar 2013
    Posts
    237

    Default

    Quote Originally Posted by macpacheco View Post
    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? ;)

  7. #7
    Join Date
    Feb 2013
    Posts
    81

    Default 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...

  8. #8
    Join Date
    Aug 2010
    Location
    Central Coast NSW
    Posts
    7

    Question 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.

  9. #9
    Join Date
    Jul 2008
    Posts
    1,725

    Default

    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.

  10. #10
    Join Date
    Dec 2013
    Posts
    17

    Default

    Quote Originally Posted by prodigy_ View Post
    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).
    Last edited by macpacheco; 12-25-2013 at 07:28 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •