Announcement

Collapse
No announcement yet.

Linux x32 Is Made Easier With Ubuntu 13.04

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by snadrus View Post
    Those shorter 32-bit instructions mean the CPU can visit more of them per second than in 64-bit (think memory bandwidth). More programs can live in the CPU cache.
    But you also get the gains of more registers over i586 (and some new instructions) which allows longer function call parameter lists to stay in CPU registers instead of going onto the stack.

    So yes, it's a slight memory benefit which is offset by having double the libraries (making no benefit), but the memory gain is in the instructions and they're upgraded 64-bit instructions. The 4gb limit downside probably doesn't apply to most software. Even a 32-bit movie player or video encoder can play files over 4gb as it doesn't keep it in-memory all the time.
    This is largely correct in principal, but wrong in ways that make my brain hurt.

    To clarify - the instructions themselves are not any shorter. Shorter instructions wouldn't allow more to run anyway, as the cpu is limited by the # of instructions it can execute, not their size.

    What is shorter is the memory addresses the program uses, which are register values the instructions operate on. Anyone who's looked at c/c++ code has seen pointers all over the place, and all of them are half the size in x32 code. I think general test cases have shown it to result in about 10% savings overall for an average codebase, although of course some programs will be more affected than others.

    The smaller pointers do allow more of the program to be cached on the chip in various places, which is what can give a speedup.

    example - code like

    mov eax ebx

    the mov instruction is the same size no matter what, it's the size of the value in eax/ebx that changes. Well, except you have to address it differently, but you get the point.
    Last edited by smitty3268; 26 April 2013, 09:57 PM.

    Comment


    • #22
      So that means a catch-all system for typical desktop use would have something like this?

      /usr/lib
      /usr/lib64
      /usr/libx32

      But I still don't see the point of x32. I mean, if you want to run 32bit stuff in a 64bit distro, you pull in the standard 32bit libraries from the package manager (like glibc, libstdc++, alsa, pulse, etc etc) and everything is fine and dandy since the combination of i686 and x64 libraries catches most, if not all the stuff needed for x64 AND 32-bit support on an x64 operating system.

      I mean, even Windows has been doing this for more than 10 years with the WoW (Windows on Windows) implementation: native x64 kernel with both the 64bit win32 stack + a stripped down 32-bit win32 stack (sans support for 8 and 16bit applications). Why go through extra trouble with x32?
      Last edited by Sonadow; 27 April 2013, 04:19 AM.

      Comment


      • #23
        Use case ?

        Originally posted by smitty3268 View Post
        Anyone who's looked at c/c++ code has seen pointers all over the place, and all of them are half the size in x32 code. I think general test cases have shown it to result in about 10% savings overall for an average codebase, although of course some programs will be more affected than others.
        And that's why you won't see much deployment on main-stream distros. Maintaining a whole 3rd set of libs & arch just isn't worth the performance gain.
        x32 just doesn't make any sense outside the academics and few very specific cases.
        For general use, just stick only to 64bits for nearly everything, and maybe install 32bits libs if you really need to run some legacy binary code which isn't available on 64bits. (e.g.: I need it to run Skype).

        You'll gain much more than x32's 10% by having a few base libraries (lib-c & co) compiled with support for all of your CPU's vector extensions. And that will require a lot less hassles to maintain as a whole separate set of arch libraries.

        Don't except a lot of x32 deployment in general purpose wide audience distros (like Fedora, openSUSE, Ubuntu).
        It will mostly be confined to Debian, Gentoo, etc. and used only by a small niche with very specific needs.

        Comment


        • #24
          Looking around a bit, it looks like Gentoo still doesn't have particularly good multilib support for x32, actually. It seems to cause people build failures due to the installation procedures doing incorrect assumptions... That's a bummer.

          Comment


          • #25
            Actually this is pretty cool. I dont know why so many people bitch around.

            I for instance have a quite new laptop with a Intel core i3 a decent AMD grapics card and 2GB of RAM. So what do I exactly need 64bit for?

            People argumented that "I should use 64bit for the small performance gain" (of course there are also some perf decreases as already pointed out, larger address space etc).

            Now we have x32 which provides exactly the performance of 64bit and even more (smaller pointer size etc), and now the same people complain "that it is not worth the performance gain"!

            C'mon that's lame.

            Comment


            • #26
              Originally posted by Nuc!eoN View Post
              Actually this is pretty cool. I dont know why so many people bitch around.

              I for instance have a quite new laptop with a Intel core i3 a decent AMD grapics card and 2GB of RAM. So what do I exactly need 64bit for?

              People argumented that "I should use 64bit for the small performance gain" (of course there are also some perf decreases as already pointed out, larger address space etc).

              Now we have x32 which provides exactly the performance of 64bit and even more (smaller pointer size etc), and now the same people complain "that it is not worth the performance gain"!

              C'mon that's lame.
              Every performance gain has a cost. The cost in this case is maintaining a whole third set of libraries on a system. That takes space, development hours, qa hours, and the performance gains have not been proven dramatic outside of a few synthetic benchmarks.

              Comment


              • #27
                Support less

                Originally posted by locovaca View Post
                Every performance gain has a cost. The cost in this case is maintaining a whole third set of libraries on a system. That takes space, development hours, qa hours, and the performance gains have not been proven dramatic outside of a few synthetic benchmarks.
                Yes, but 32-bit-only x86 hardware is becoming obsolete, and most for-Linux software is following. A distro could support only the handful of 64-bit programs they must (drivers & those like what I listed), then have x32 for the rest.

                Comment


                • #28
                  This sounds perfect for some old console emulators that seem to work best on x86 systems.

                  Comment


                  • #29
                    Originally posted by snadrus View Post
                    Yes, but 32-bit-only x86 hardware is becoming obsolete, and most for-Linux software is following. A distro could support only the handful of 64-bit programs they must (drivers & those like what I listed), then have x32 for the rest.
                    Maybe new hardware, but there are millions upon millions of existing systems that are not 64 bit and no distribution is going to drop x86 and alienate those users.

                    Comment


                    • #30
                      I remember reading that a significant niche could be in virtual machines. What If you're renting some Xen guest with 512MB ram, or anything < 3.5GB, with some "half a core" guarantee : then that linux server would just run pure x32 and you get a free performance gain - assuming you only had to choose to run a debian x32 installer, or an x32 variant of ubuntu 14.04 or something else. Even the provider would be happy from small electricity savings or cramming one more VM on the server.

                      Maybe ARMv8 will do the very same thing?

                      As for desktops it'd be a pain in the ass (no nvidia x32 driver, x32 flash player, and what about just downloading and running a static build of some software) so don't bother, unless maybe you can run full open source everything and install such a clean x32 system on an old computer.
                      I still run pure i686 on my desktop (I have a x86 CPU, but "only" 3GB RAM, up from 2GB. Also if my computer dramatically fails I can still put the IDE hard drive in some piece of crap Pentium 4; or if my PC doesn't fail I can make an installation on a new hard drive, and reuse the old OS in an old PC)

                      Comment

                      Working...
                      X