On Fri, Feb 5, 2010 at 7:17 AM, Duncan <[email protected]> wrote: > 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 > difference. > > 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 >> extension. > > 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.
Hi Duncan, 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. Regards, Martin
