Announcement

Collapse
No announcement yet.

Ubuntu 11.04: i686 vs. i686 PAE vs. x86_64

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

  • Ubuntu 11.04: i686 vs. i686 PAE vs. x86_64

    Phoronix: Ubuntu 11.04: i686 vs. i686 PAE vs. x86_64

    At the end of 2009 I published benchmarks comparing Ubuntu's 32-bit, 32-bit PAE, and 64-bit Linux kernels. Those tests were carried out to show the performance impact of using 32-bit with PAE (Physical Address Extension) support, which on the plus side allows up to 64GB of system memory to be addressable from 32-bit machines, but is still significantly slower than a 64-bit kernel and user-space. In this article the tests have been carried out on modern hardware and with the latest Ubuntu 11.04 packages to see how the three kernel variants are performing in 2011.

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Nice article Michael. Hopefully it is enough to open some of the old die hards eyes.

    Comment


    • #3
      Any chance you could redo those graphs with colors that are easier to tell apart?

      Comment


      • #4
        include AMD CPUs!

        Nice to see that x64 proves its worth.

        However, why isn't a recent AMD cpu included?
        AMD and Intel chips have different strengths and articles such as these should show fair comparisons.

        Also, the tests where the i7 is slower in x64 than in x32 actually show some of the weaknesses of the Intel architecture.

        Comment


        • #5
          Graph bars are all green. Took a near superhuman effort to distinguish one from the other.

          Comment


          • #6
            I agree with the point of the article that 64-bit should be the default / "recommended" version. Canonical should ship the beta of Adobe Flash 10.3 "Square" 64-bit whenever a user requests a flash install (or if they check the third-party software box at install-time), thus pressuring Adobe to finalize 64-bit support and make Flash update releases of 64-bit in lock-step with 32-bit.

            The Java problem is mostly solved with the new browser plugin released by IcedTea. We should see a great out of the box experience on distros that ship this plugin for both 32-bit and 64-bit, especially once OpenJDK 7 goes stable.

            The few places where 64-bit did worse, I think are regressions that could be fixed in the app. For the 3d stuff, it's not surprising that the numbers are unchanged or worse for 64-bit, because the main thing being tested there is CPU context switches (for all the graphics calls) and GPU performance, not CPU throughput.

            I'm a bit surprised at the good performance of PAE, but I guess it's because more stuff can be stored in the page cache, which really makes a difference on that 8GB system. Even with the extra level of PTEs, having twice the space for caching pages off of disk is going to be a major speed-up if you can load most of or all of your on-disk dataset into RAM and work with it there. Running a PAE kernel on a system with < 4 GB of RAM would probably degrade performance overall, though, and certainly wouldn't improve it.

            The few 32-bit binary blobs that remain laying around that people still sometimes use -- TeamSpeak, Shoutcast Server, Win32 programs under Wine, a few of the Humble Bundle games, etc -- can be made to work fine under a 64-bit kernel by installing the correct 32-bit libs. I guess this is Canonical's fear: that a significant part of the userbase would bee-line straight to wanting to run 32-bit-only nonfree programs that require a great number of 32-bit dependencies that Ubuntu does not ship under lib32* packages. Oh no, they'd have to learn how to use getlibs or compile them from source. Or even worse, Ubuntu would have to fully and truly support multi-arch like OpenSUSE. The horror. Worse yet -- users would have to learn to use free software alternatives to the 32-bit-only binary blobs that they "rely" upon. Unthinkable! (It is the case that, generally speaking, all free software targeting Linux compiles and runs cleanly on amd64 -- show me a counterexample and I'll help make it work with 64-bit if I know the programming language it's written in.)

            Hell, even Microsoft is ahead of Ubuntu in this regard. Windows Server 2008 R2, the server release of Windows based on the same build as Windows 7, only comes in an amd64 flavor. You can't even get a 32-bit build of Windows NT 6.1 Server. It doesn't exist. And all of your favorite server programs, from SQL Server to Server Manager, come as 64-bit userspace apps. I am further impressed by the fact that Microsoft Word ships a 64-bit build! Lastly, there are rumors (though unconfirmed) that Windows 8 will ship 64-bit-only for all product lines, both desktop and server. They might well release a 32-bit version of Windows Starter for those cheap emachines and stuff, but Home Premium / Professional / Ultimate / Server will all probably ship 64-bit only.

            Seems to me like Adobe and a few other ultraconservative companies are retarding the progress of Linux 64-bit adoption by intimidating distributions into thinking that making 64-bit the default would inconvenience or scare away newbies. Whether they're doing this intentionally, or just refusing to change, or doing it to save engineering money, the fact remains that if we were to disregard all the proprietary companies that refuse to make 64-bit Linux builds, we would have nothing left to complain about, and Ubuntu could "safely" recommend 64-bit.

            To see the kind of corporate mentality that leads to companies snubbing 64-bit builds, see here and search for replies by a name ending in "Linden" for the reasons given by Linden Lab employees for not offering a 64-bit build of Second Life.

            But the demand for a 64-bit viewer was so great that community members contributed patches to the open source side of Second Life viewer development, and it works well enough these days that it's 100% feature-equivalent and much faster than the 32-bit build. To this day it seems only 64-bit Linux has been ported, with no indication of if/when 64-bit Windows builds will be available. Kokua and Imprudence viewers support 64-bit Linux for some time now.

            Also interesting are some of the arguments here for specifically a 64-bit Linux viewer (no Linden Lab employee replies there yet). If you look at http://popcon.ubuntu.com (PopCon = Popularity Contest, not "popCORN" the food), you'll see that the graphs of i386 vs amd64 are clearly converging over time. The only reason they haven't already converged is that so many people are afraid to do something other than the "recommended", so they just accept the default 32-bit build that Ubuntu pushes on people. Classic chicken and the egg problem, as a microcosmic instance of the global plight of the FOSS movement.

            Comment


            • #7
              You know, I think this has explained something for me. Recently, I had Fedora 12 with a 2.6.31 32 bit PAE kernel. I now have openSUSE 11.4 with a 2.6.37 64 bit kernel on the same machine. On the Fedora system, when I ran Linpack, I got about 80.1 GFLOPS. Now, I get about 94.8 GFLOPS. I wasn't sure how that had changed, but I think this explains it well. Thankyou.

              Comment


              • #8
                Why Canonical is not promoting x86_64?

                First of all, some of the main and most popular third party software don't have 64bit support. Skype, Adobe Reader, Adobe Flash Player among other ones.
                In particular the latter is known to be important (if not mandatory) for web contents.
                And they don't want to have users getting bad web experience from Ubuntu.

                Second, in a number of places you can read that a 64bit desktop PC is not that faster than a 32bit conterpart. If that's not a urban legend, it's at least a common belief none has cleared so far. So let's stay on the mainstream.

                Third, yours (Phoronix') is among the very few comparisons I've seen so far between 32bit and 64bit system. And most of the users and decision makers can struggle a lot to understand the real meaning of it. Companies rarely aim products and services to "geeks", any way.

                Fourth. People coming from the Microsoft world (that's not me) "know" that there "can be problems" in getting 64bit working drivers and software if they choose a 64bit OS. Yes, they can still run 32bit stuff in a 64bit environemnt, but then, why should they?
                So proposing users the same choice they'd hear from the "normal" world brings more trust. That's money.

                In the end, all that could be just ignorance in it's broader meaning. But this is the "real world" (tm) where a PC sells better than an Amiga or an Archimedes. Sigh!

                Comment


                • #9
                  I think canonical is clearly thinking about changing this.

                  They are including the newest work for multi-arch on dpkg that's not even in debian in the next release: it is clearly a first step towards better integration of a mixed 32bit/64bit system, and after getting that working they'll probably start recommending 64-bit.

                  Remember that mixing 32bit and 64bit packages in ubuntu isn't so easy or trouble-free as for example with openSUSE.

                  Comment


                  • #10
                    Originally posted by [Knuckles] View Post
                    I think canonical is clearly thinking about changing this.
                    The sooner the better.

                    Originally posted by [Knuckles] View Post
                    Remember that mixing 32bit and 64bit packages in ubuntu isn't so easy or trouble-free as for example with openSUSE.
                    Why bothering? To run Skype and Flash player? I'd dump them and push for products that either support 64bits or, better, come with source code you can compile at 64bit.

                    Comment

                    Working...
                    X