Ubuntu 11.04: i686 vs. i686 PAE vs. x86_64

[whitecat]

IBM Corporation (2007-09-06). "IBM WebSphere Application Server 64-bit Performance Demystified". p. 14. Retrieved 2010-04-09. ""Figures 5, 6 and 7 also show the 32-bit version of WAS runs applications at full native hardware performance on the POWER and x86-64 platforms. Unlike some 64-bit processor architectures, the POWER and x86-64 hardware does not emulate 32-bit mode. Therefore applications that do not benefit from 64-bit features can run with full performance on the 32-bit version of WebSphere running on the above mentioned 64-bit platforms.

[kobblestown]

schroot

To me the only reason for sticking with 32-bit (apart from having very resource constrained, i.e. old system) would he drivers. If you have some device that has only 32-bit drivers available then you're stuck. No point of arguing "one shouldn't buy crappy hardware." Sometimes you just have to live with what you've got.

At the application side, I think the problem is mostly solved. Sun's JRE has had a 64-but plugin since about one year (maybe more, I don't remember exactly). I hear IcedTea has it too. You can run 32-bit plugins in a 64-bit browser thanks to nspluginwrapper (or whatever the name was). The only 32-bit applications that I use are Skype and Adobe Acrobat Reader. The former comes in a deb package which takes care of lib32 dependencies. For the latter I use schroot.

Root jails are very nice way to deal with 32-bit applications. You can have entire 32-bit distribution in a directory and install your 32-bit stuff there. I only bother to do this for Acrobat Reader because it has plenty of dependencies which I have to install by hand since it comes in tar.gz file. Then, if I happen to install a new host distribution from scratch, I just have to bring over the directory tree of the root jail, configure schroot for easy switch to the jail and voila - I have Acrobat Reader. I strongly recommend schroot for managing root jails - it works like a charm. Especially with debootstrap for debian-based distributions. You can set up a new one in no time.

The use of 32-bit application under a 64-bit kernel does bring one issue which I would have liked to see addressed by the article. I wonder what is the performance impact of running 32-on-64 as opposed to 32-on-32. Such test can easily be performed on the original 64-bit setup - install a 32-bit version in a root jail and run the tests from there. So, Michael, if you're reading this, please do it. It will be hugely appreciated. Of course, I could do this myself for my own computer, but it will be more relevant to put it in the context of the original test.

[fhuberts]

multiarch

Fedora has had multiarch since the 'beginning'.

[chithanh]

I agree with fhuberts that an AMD CPU should have been included in the test too. At least in the old days, the performance difference between 32 bit and 64 bit was higher on AMD than on Intel.

One more reason for Canonical to not promote 64 bit could be that 32 bit works better in memory constrained environments (e.g. a system with <512 MB RAM and integrated graphics).

[Uqbar]

I think canonical is clearly thinking about changing this.

The sooner the better.

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.

[[Knuckles]]

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.

[Uqbar]

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!

[PreferLinux]

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.

[allquixotic]

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.

[russofris]

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