On Mon, 11 Dec 2006 11:30:05 -0500
"Greg A. Woods" <woods@weird.com> wrote:

> > So... if you don't NEED to run in 64 bit mode... then stick to 32 bit 
> > mode. You'll likely get better performance from your system. Regardless 
> > of whether the 64bit OS is or is not ready for production. :)  
> 
> I'd like to see some proof of better performance in 32-bit mode --
> beyond that of just showing larger resident working sets for a given
> process.  I've seen some more concrete evidence of this in the
> UltraSPARC world, but nothing yet for AMD64.

It's worth keeping an eye on the detailed releases associated
with the SPEC CPU benchmarks, on this point.  A lot of the
earliest AMD64/EM64T results used 32-bit compiler models and
operating systems for performance, but I think that this time has
largely passed, at least for some compilers.  Looking at the
CPU2006 results just now, it seems that there are only a couple of
the individual tests that run fastest (as observed by being how
they were submitted) in 32-bit mode.  I imagine that these are
probably pointer-chasing-ish things.  Almost all of the floating
point results and a large fraction of the integer results seem to
use LP64 mode as their fastest, now.  I'd say that that means that
the architectural advantage of more registers and better calling
conventions trumps D-cache pressure from long pointers more often
than not.  There's probably still only a whisker in it, of
course.  I run my own system in AMD64-mode because it's more
fun :-)

Don't forget that there's another effect in BSD-land: off_t and
many of the on-disk and timer-related objects are 64-bit types
even on 32-bit processors, now.  I don't know how much impact that
has on anything, but it can't hurt comparative performance.

Cheers,

-- 
Andrew