[kwlug-disc] [Phoronix] Ubuntu 32-bit, 32-bit PAE, 64-bit Kernel Benchmarks
chris at chrisirwin.ca
Thu Dec 31 12:35:57 EST 2009
On Thu, Dec 31, 2009 at 12:04, Lori Paniak <ldpaniak at fourpisolutions.com>wrote:
> On Thu, 2009-12-31 at 10:22 -0500, Chris Irwin wrote:
> > 1. He was using Ubuntu, so it was i386 vs modern AMD64. So how much of
> > this was affected by having things like SSE, etc. There was a request
> > to try using an i686-targetted system (such as Arch). There was also a
> > request to use gentoo and actually build the system with the same
> > capabilities for 32- and 64-bits, but I doubt anybody wants to spend
> > two weeks doing that ;)
> As is typical with standardized benchmarks, there is a pound of salt to
> be digested as well. The only benchmarks that make sense are ones of
> your typical usage pattern.
> One probably does not have to go as far afield as Arch or Gentoo to get
> i686 results along with AMD64 and i386. Debian ships kernels in each of
> these flavours (i486 too). With Debian, much of the test environment
> should just be a copy-and-paste from ubuntu.
The issue was two part: Is it the kernel alone that provides improvement
(try 64-bit kernel with 32-bit i386 userspace) or was it the fact that
compiling targeting amd64 enables all sorts of cpu features that are not
present on i386 (mmx, sse, etc). Using these capabilities may cause GCC to
compile certain applications differently.
Lets take SSL as the standout example. A fair amount of the improvement will
be coming from extra registers as part of the amd64 platform. But some of
the improvement may be simply that the compiler knew it had SSE and other
modern hardware capabilities available and was able to create a better
binary. Having a 32-bit userspace that targeted a modern CPU's capabilities
would provide a more interesting comparison from a technical point of view
(what gives more benefit: 64-bit or knowing the capabilities of your CPU and
hardware). Granted, from a user point of view it doesn't matter as the
average user (myself included) is just going to run whatever bits Ubuntu
But it would give all those gentoo folk with massive lists of CFLAGS
something to gloat about.. Actually, that is probably bad. ;)
> > Also, not to nitpick (though I do so love playing the part), but your
> > short summary read like "64-bit isn't worth it except in these
> > specific instances". I read the article as coming more across as
> > "There are no regressions, but you may get improved performance in
> > specific instances". Subtle difference, but it would affect whether
> > somebody decided to install a 32- or 64-bit system.
> I agree with your more precise summary. My own view is that if you have
> a 64-bit CPU, you should run a 64-bit OS. Since AMD has been making
> 64-bit CPUs for 6+ years and Intel for 4 years, there are fewer and
> fewer situations that require 32-bit systems. Performance gains
> suggested in this article just reinforce this view (even with the
> i386/i686 caveats). Now that virtualization environments support 64-bit
> guests and many netbook-class CPUs are 64-bit, I am not sure how one
> makes the argument for 32-bit OS on new hardware (ex-basic netbooks).
I agree. I wish (as pointed out in another email) that Ubuntu and Debian had
a better 32-bit compatibility capability, though.
Since you opened the Virtualization can-of-worms, Linux has awesome support
for this built-in with KVM now. The only issue is it needs special support
on-chip. This means VT for Intel, and AMD-V for AMD. At least when you buy
an AMD processor, all of them are 64-bit and AMD-V capable, with the
exception of the Sempron, which is not the latter.
Intel on the otherhand, you have to look up every chip to see if it is VT
capable. An example: The T5500 and T5600 processors have VT, while the T5550
and T5670 do not (one would assume they were simply improved versions of
their predecessors). It made it very difficult to purchase a new laptop
since most manufacturers do not indicate what specific processor is within.
Interestingly, all of their "su" low-power processors are VT capable, even
though I would imagine that is not their target market...
> For the desktop user, I think this is the most relevant test where the
> 32/64-bit question comes up. I use ecryptfs for my home as well - with
> 64-bit karmic on a 2.2Ghz Intel T7500 mobile Conroe. If you have
> similar hardware and 32-bit OS, we could compare disk I/O numbers on
Sadly no, 64-bit only.
<chris at chrisirwin.ca>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kwlug-disc