martin at herrman
Feb 5, 2010, 3:23 AM
Post #2 of 4
On Fri, Feb 5, 2010 at 7:17 AM, Duncan <1i5t5.duncan [at] cox> wrote:
Re: 32-bit, 32-bit PAE, 64-bit benchmarks
[In reply to]
> Here's a phoronix benchmarking article I came across that I thought would
> interest people here. Using an Intel Core 2 Duo T9300 machine with 4 gigs
> RAM, they benchmark a normal 32-bit kernel (which limits to 3 gig
> accessible due to the PCI device I/O window just below the 32-bit 4-gig
> barrier), a 32-bit PAE kernel, and a 64-bit kernel. The distribution was
> Ubuntu 9.10.
> One thing I did NOT see them specify, is whether on the 64-bit kernel,
> they were using a 32-bit userland, or 64-bit. That could make some
> Apparently, Linus has claimed a 25% performance penalty using PAE.
> However, they don't link that claim and I didn't google it, so I don't
> know the context. In particular, I don't know whether he was claiming the
> penalty as compared to 32-bit standard, with its memory limitations, or as
> compared to 64-bit. If the latter, certainly, these benchmarks
> demonstrate he was being conservative, if anything, in some areas.
> One other point to note. As we're talking binary based Ubuntu here, the
> 32-bit versions will be much more generically optimized, since they cater
> to a much broader hardware base, than the 64-bit, which by virtue of its
> being a much newer standard, can and does define as available some SSE and
> etc extensions that 32-bit, compiled as generically as Ubuntu does, will
> not be able to take advantage of. I really do wish I knew whether the 64-
> bit benchmarks were done using the 64-bit Ubuntu userspace or the 32-bit
> user-space, but if they say, I didn't see it. But if it's the 64-bit
> userspace, the extra optimizations possible with 64-bit will make some
> difference as well. Of course, also coming into play is likely the
> CFLAGS, etc, the phoronix test suite itself was built with.
> But regardless of those details, the benchmarks speak for themselves.
> Gaming/OpenGL, not much difference (so little they included only one
> graph, "to avoid repetition"), but WOW, check out some of the other
> benchmarks! Certainly as memory capacities reach and exceed 4 GB, the
> article's conclusion is valid, basically, don't bother monkeying around
> with 32-bit PAE and CONFIG_HIGHMEM64G, just do it right and go full 64-
> bit. Or as they put it:
>> Unless you have technical or business reasons for not migrating to
>> 64-bit Linux with compatible hardware, there is no reason to stick
>> around with a 32-bit kernel and worrying about physical address
> That said, one /does/ wonder what the results would have been like, had
> they been comparing 32-bit compiled with -O2 -march=native against 64-bit
> compiled similarly, basically, the Gentoo recommended defaults. I expect
> that would have increased 32-bit performance somewhat, possibly even
> narrowly beating out 64-bit where the differences aren't that great in the
> benchmarks as-is.
I'm quite interested in this subject, in my profession I advise
organisations on performance and availability of their services. Can
you provide a link to the article?
Maybe we should just ask them if they used 32 or 64 bit userland?
I know of an organisation that switched to 64-bit java application
server, which is good if you need java processes that need more than 3
GB. But.. almost all of the java processes need only max. 1GB. The
memory-overhead of 64-bit addresses in the java process for these
processes is significant: after upgrading to 64-bit userland, more
memory was required on the servers. I have no information available on
the performance impact 32-bit userland-only vs. full 64-bit.