If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Ubuntu 11.04: i686 vs. i686 PAE vs. x86_64

04-04-2011, 01:00 AM

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.

Comment

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

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

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

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.