Why is 64 bit faster. RE: [Beowulf] Win64 Clusters!!!!!!!!!!!!
Henderson, T Todd @ IS
Todd.Henderson at L-3Com.com
Wed Apr 11 11:31:40 PDT 2007
O.k. I'm going to ask, what I'm sure is a stupid question, actually 2.
1.) Why is a 64 bit cpu faster? I had assumed the main benefit was the
memory that could be addressed, obviously a bad assumption.
2.) If you install the 32 bit version of an os, say linux, instead of
the 64 bit version and then run 32 bit apps, do you get the speedup?
From: beowulf-bounces at beowulf.org [mailto:beowulf-bounces at beowulf.org]
On Behalf Of Robert G. Brown
Sent: Wednesday, April 11, 2007 2:17 AM
To: Jon Forrest
Cc: Beowulf Mailing List
Subject: Re: [Beowulf] Win64 Clusters!!!!!!!!!!!!
On Sun, 8 Apr 2007, Jon Forrest wrote:
> The experiment I tried was to build several fairly large programs on
> Fedora Core 6 32 bit and then 64 bit using exactly the same hardware.
> This is clearly not the same kind of test as your example but it's
> more relevant as a systems-level comparison.
> If I remember, I built mysql and apache. This took about the same
> amount of time in both modes.
Building programs isn't a particularly good benchmark for anything but
building programs, for all that people tend to use make as a benchmark
anyway. RUNNING programs (other than make and gcc) is much better. For
one thing, compilers tend to basically be parsing engines processing
text, with very little advantage available due to e.g. optimizing loops
or streaming in double precision data to do a complex numerical
> I suspect that the Beowulf crowd would have lots of experience with
> 32-bits vs 64-bits question, so I'd welcome additional comments,
> especially dealing with situations where programs
> *don't* need the additional address space of the 64-bit model.
Sure. 64-bits = "good". 32-bits = "bad", in nearly all CPU-intensive
(especially floating point intensive) applications that don't thrash the
cache. Cache thrashing is actually more expensive IIRC for 64 bit
systems than it is for 32 bit systems because the penalty for a cache
miss is higher. For pretty much everything else, though, goood. And
even where it is bad it isn't THAT bad because its good at least partly
Size of the program isn't terribly important to this conclusion, as
Toone's miniprogram clearly shows. You don't need a lot of code to do a
long-running double precision loop.
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb at phy.duke.edu
Beowulf mailing list, Beowulf at beowulf.org To change your subscription
(digest mode or unsubscribe) visit
More information about the Beowulf