Page 1 of 4 123 ... LastLast
Results 1 to 10 of 35

Thread: x32 Support For Linux Kernel Called In For Review

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

    Default x32 Support For Linux Kernel Called In For Review

    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

  2. #2
    Join Date
    Nov 2010
    Location
    Stockholm, Sweden
    Posts
    405

    Default

    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?

  3. #3
    Join Date
    Jul 2010
    Posts
    492

    Default

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

  4. #4
    Join Date
    Sep 2010
    Posts
    55

    Default

    Quote Originally Posted by log0 View Post
    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?

  5. #5

    Default

    Quote Originally Posted by werfu View Post
    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.
    Last edited by chris200x9; 02-20-2012 at 09:53 AM.

  6. #6
    Join Date
    Nov 2008
    Location
    Madison, WI, USA
    Posts
    874

    Default

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

  7. #7
    Join Date
    Aug 2007
    Posts
    6,631

    Default

    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.

  8. #8
    Join Date
    Oct 2009
    Posts
    845

    Default

    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.

  9. #9
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,105

    Default

    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.

  10. #10
    Join Date
    Oct 2008
    Posts
    3,135

    Default

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

Posting Permissions

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