public inbox for gentoo-amd64@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-amd64] 32-bit, 32-bit PAE, 64-bit benchmarks
@ 2010-02-05  6:17 Duncan
  2010-02-05 11:23 ` Martin Herrman
  2010-02-05 16:46 ` [gentoo-amd64] " Volker Armin Hemmann
  0 siblings, 2 replies; 4+ messages in thread
From: Duncan @ 2010-02-05  6:17 UTC (permalink / raw
  To: gentoo-amd64

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.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [gentoo-amd64] 32-bit, 32-bit PAE, 64-bit benchmarks
  2010-02-05  6:17 [gentoo-amd64] 32-bit, 32-bit PAE, 64-bit benchmarks Duncan
@ 2010-02-05 11:23 ` Martin Herrman
  2010-02-05 13:58   ` [gentoo-amd64] " Duncan
  2010-02-05 16:46 ` [gentoo-amd64] " Volker Armin Hemmann
  1 sibling, 1 reply; 4+ messages in thread
From: Martin Herrman @ 2010-02-05 11:23 UTC (permalink / raw
  To: gentoo-amd64

On Fri, Feb 5, 2010 at 7:17 AM, Duncan <1i5t5.duncan@cox.net> 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



^ permalink raw reply	[flat|nested] 4+ messages in thread

* [gentoo-amd64] Re: 32-bit, 32-bit PAE, 64-bit benchmarks
  2010-02-05 11:23 ` Martin Herrman
@ 2010-02-05 13:58   ` Duncan
  0 siblings, 0 replies; 4+ messages in thread
From: Duncan @ 2010-02-05 13:58 UTC (permalink / raw
  To: gentoo-amd64

Martin Herrman posted on Fri, 05 Feb 2010 12:23:45 +0100 as excerpted:

> Can you provide a link to the article?

I knew I hadn't as soon as I hit the send button... =:^(

But then the thing wouldn't show up, and wouldn't show up, and wouldn't 
show up, for me to reply to properly with the link... for well over an 
hour, until I gave up, bookmarked the link for whenever, and got absorbed 
in something else.

Now I'm checking back to post the link, and as expected, there's someone 
calling attention to the fact that I missed it! =:^\  (But thanks.  If I
/hadn't/ known it, I'd be glad /someone/ spotted it!)

Anyway, provided the bookmark function did what it's supposed to do... one 
begins to wonder with the luck I've had on this one...

http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae&num=1

Seems the bookmark worked, now let's see if the posting still does!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [gentoo-amd64] 32-bit, 32-bit PAE, 64-bit benchmarks
  2010-02-05  6:17 [gentoo-amd64] 32-bit, 32-bit PAE, 64-bit benchmarks Duncan
  2010-02-05 11:23 ` Martin Herrman
@ 2010-02-05 16:46 ` Volker Armin Hemmann
  1 sibling, 0 replies; 4+ messages in thread
From: Volker Armin Hemmann @ 2010-02-05 16:46 UTC (permalink / raw
  To: gentoo-amd64

about optimizing:

when you install pts on 32bit all the tests are optimizied.
on 64bit there are many which are not.

So you asked your question the wrong way.

How big would be distance between 64 and 32bit if pts would not suck and 
prefer 32bit?



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2010-02-05 16:47 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-05  6:17 [gentoo-amd64] 32-bit, 32-bit PAE, 64-bit benchmarks Duncan
2010-02-05 11:23 ` Martin Herrman
2010-02-05 13:58   ` [gentoo-amd64] " Duncan
2010-02-05 16:46 ` [gentoo-amd64] " Volker Armin Hemmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox