Hello all,

I am assembling a cluster for some computational work. I have to make the
hardware choice between traditional 32-bit systems and the newer 64-bit
systems that have recently been released by AMD and Intel.

The programs that will be running are very math-heavy and use double
precision floats (generally assumed to be 64 bits of information). The
question I have is: while the 64-bit architecture is sexy, does it actually
provide a performance gain? Would a 64-bit processor multiply two doubles
twice as fast as a 32-bit processor?

Any help would be apprciated, thanks.
Arnab Chowdry

On Tue, 1 Feb 2005 20:19:50 -0800, "Arnab Chowdry"
<(E-Mail Removed)> wrote:

>Hello all,
>
>I am assembling a cluster for some computational work. I have to make the
>hardware choice between traditional 32-bit systems and the newer 64-bit
>systems that have recently been released by AMD and Intel.
>
>The programs that will be running are very math-heavy and use double
>precision floats (generally assumed to be 64 bits of information). The
>question I have is: while the 64-bit architecture is sexy, does it actually
>provide a performance gain? Would a 64-bit processor multiply two doubles
>twice as fast as a 32-bit processor?
>
>Any help would be apprciated, thanks.
>Arnab Chowdry
>

This is 32 bit software, right?
No you aren't going to get the kind of benefit you describe
in that case BUT you might still benefit from the superior
architecture of the Athlon 64, regardless of it having 64bit
abilities too.

Generally with such conputation, one large factor is how
much L2 cache it needs. You might find substantial benefit
from a CPU with "enough" cache... but I can't advise on
whether your particular use would need 256, 512, 1024K or ?
Benchmarks of various CPUs, their performance relative to
their L2 cache size might be revealing. For example, if a
Celeron 800 is FAR slower than a P3 800, you're benefiting
from the P3's 256K L2 cache. Likewise, comparing an Athlon
Barton 512K L2, to a regular Athlon XP with only 256K L2,
or a P4 Northwood w/512K to a Prescott with 1MB.

On Tue, 01 Feb 2005 20:19:50 -0800, Arnab Chowdry wrote:

> Hello all,
>
> I am assembling a cluster for some computational work. I have to make the
> hardware choice between traditional 32-bit systems and the newer 64-bit
> systems that have recently been released by AMD and Intel.
>
> The programs that will be running are very math-heavy and use double
> precision floats (generally assumed to be 64 bits of information). The
> question I have is: while the 64-bit architecture is sexy, does it actually
> provide a performance gain? Would a 64-bit processor multiply two doubles
> twice as fast as a 32-bit processor?
>
> Any help would be apprciated, thanks.
> Arnab Chowdry

Your best choice is a set of dual Opteron servers. The 64 bitness isn't
the primary advantage, it's the short pipelines, low memory latency and
high memory bandwidth that matters. Each Opteron has it's own memory
controller, as opposed to the Xeon which has a shared memory controller.
The dedicated memory controllers are a huge advantage because they give a
dual Opteron system nearly twice the bandwidth of a dual Xeon system. In
addition the memory latency is much lower on an Opteron. The short
pipeline on the Opteron/Athlon 64 is an even bigger advantage. My
benchmarking of my Athlon 64 laptop (which only has a single memory
channel vs two on the 939 pin Athlon 64s and the 940 pin Opterons) showed
that the an 2.2GHz Athlon 64 3400+ is twice as fast as a 2.66GHz Xeon
doing Verilog simulations. Verilog simulations don't use floating point so
my results aren't a perfect for your application but that should give you
an idea of the relative performance of the A64 architecture vs the Intel
P4 architecture.

"Arnab Chowdry" <(E-Mail Removed)> wrote in message news:ctpkcp$g22$(E-Mail Removed)...
> Hello all,
>
> I am assembling a cluster for some computational work. I have to make the
> hardware choice between traditional 32-bit systems and the newer 64-bit
> systems that have recently been released by AMD and Intel.
>
> The programs that will be running are very math-heavy and use double
> precision floats (generally assumed to be 64 bits of information). The
> question I have is: while the 64-bit architecture is sexy, does it actually
> provide a performance gain? Would a 64-bit processor multiply two doubles
> twice as fast as a 32-bit processor?

Since you are planning to some very math heavy computation,
you might want to consider a system with the highest data
integrity, i.e., the having the least chance of your results getting
corrupted because of memory errors occurring during computation.
Memory is the weakest link in a standard PC configuration with
respect to data integrity. According to a white paper published in
January 2004 by Tezzaron Semiconductor, a PC with 512MB of
memory running 24 hours a day will sustain a memory error about
every 10 days. (Reference:
http://www.tezzaron.com/about/papers...1%20secure.pdf
See Appendix B, Calculations, on page 6).

For the highest memory integrity for a reasonable price, consider an
Opteron CPU, an ASUS SK8V mainboard, and -x4 bitwidth memory
modules such as Crucial CT6472Y335.18LFC4. This configuration
will give you an advanced form of ECC known as "Chipkill".

-- Bob Day
http://bobday.vze.com

It currently is compiled as "32-bit" software, but as its a library that is
developed in the lab, I see no problems in porting it to 64-bit compilers.
None of the code depends on sizeof(int) being fixed to 32 bits.

So, if the question is if it would be compiled as a native 64bit
application, then the answer is yes.

-Arnab

"kony" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Tue, 1 Feb 2005 20:19:50 -0800, "Arnab Chowdry"
> <(E-Mail Removed)> wrote:
>
>>Hello all,
>>
>>I am assembling a cluster for some computational work. I have to make the
>>hardware choice between traditional 32-bit systems and the newer 64-bit
>>systems that have recently been released by AMD and Intel.
>>
>>The programs that will be running are very math-heavy and use double
>>precision floats (generally assumed to be 64 bits of information). The
>>question I have is: while the 64-bit architecture is sexy, does it
>>actually
>>provide a performance gain? Would a 64-bit processor multiply two doubles
>>twice as fast as a 32-bit processor?
>>
>>Any help would be apprciated, thanks.
>>Arnab Chowdry
>>
>
> This is 32 bit software, right?
> No you aren't going to get the kind of benefit you describe
> in that case BUT you might still benefit from the superior
> architecture of the Athlon 64, regardless of it having 64bit
> abilities too.
>
> Generally with such conputation, one large factor is how
> much L2 cache it needs. You might find substantial benefit
> from a CPU with "enough" cache... but I can't advise on
> whether your particular use would need 256, 512, 1024K or ?
> Benchmarks of various CPUs, their performance relative to
> their L2 cache size might be revealing. For example, if a
> Celeron 800 is FAR slower than a P3 800, you're benefiting
> from the P3's 256K L2 cache. Likewise, comparing an Athlon
> Barton 512K L2, to a regular Athlon XP with only 256K L2,
> or a P4 Northwood w/512K to a Prescott with 1MB.
>

On Wed, 2 Feb 2005 14:31:17 -0800, "Arnab Chowdry"
<(E-Mail Removed)> wrote:

>It currently is compiled as "32-bit" software, but as its a library that is
>developed in the lab, I see no problems in porting it to 64-bit compilers.
>None of the code depends on sizeof(int) being fixed to 32 bits.
>
>So, if the question is if it would be compiled as a native 64bit
>application, then the answer is yes.
>
>-Arnab

While that clarifies a point to which other posters might
address, I can't project what performance difference that
might yield.

On Thu, 03 Feb 2005 02:05:01 GMT, kony <(E-Mail Removed)> wrote:

>On Wed, 2 Feb 2005 14:31:17 -0800, "Arnab Chowdry"
><(E-Mail Removed)> wrote:
>
>>It currently is compiled as "32-bit" software, but as its a library that is
>>developed in the lab, I see no problems in porting it to 64-bit compilers.
>>None of the code depends on sizeof(int) being fixed to 32 bits.
>>
>>So, if the question is if it would be compiled as a native 64bit
>>application, then the answer is yes.
>>
>>-Arnab
>
>While that clarifies a point to which other posters might
>address, I can't project what performance difference that
>might yield.

Theres some benchmarks I remember but I dont know if they pertain to
exactly his appliction. I also recall people used to say youd get a
10-20% increase if you recomiled some progs into 64 bit apps but
have no idea once again if it pertains to his application.
http://www.xbitlabs.com/articles/cpu...4-3800_11.html

I also remember something about even plain old Athlon XPs being
particularly good for "scientific calculations" but once again dont
know if thats relevant to his specific question.

Bob Day wrote:

> "Arnab Chowdry" <(E-Mail Removed)> wrote in message
> news:ctpkcp$g22$(E-Mail Removed)...
>> Hello all,
>>
>> I am assembling a cluster for some computational work. I have to make the
>> hardware choice between traditional 32-bit systems and the newer 64-bit
>> systems that have recently been released by AMD and Intel.
>>
>> The programs that will be running are very math-heavy and use double
>> precision floats (generally assumed to be 64 bits of information). The
>> question I have is: while the 64-bit architecture is sexy, does it
>> actually provide a performance gain? Would a 64-bit processor multiply
>> two doubles twice as fast as a 32-bit processor?
>
> Since you are planning to some very math heavy computation,
> you might want to consider a system with the highest data
> integrity, i.e., the having the least chance of your results getting
> corrupted because of memory errors occurring during computation.
> Memory is the weakest link in a standard PC configuration with
> respect to data integrity. According to a white paper published in
> January 2004 by Tezzaron Semiconductor, a PC with 512MB of
> memory running 24 hours a day will sustain a memory error about
> every 10 days. (Reference:
> http://www.tezzaron.com/about/papers...1%20secure.pdf
> See Appendix B, Calculations, on page 6).
>
> For the highest memory integrity for a reasonable price, consider an
> Opteron CPU, an ASUS SK8V mainboard, and -x4 bitwidth memory
> modules such as Crucial CT6472Y335.18LFC4. This configuration
> will give you an advanced form of ECC known as "Chipkill".
>
> -- Bob Day
> http://bobday.vze.com

That may be true "on paper" but in reality its a myth. For example,
I've got a system thats been running 24/7 for 125 days now with absolutely
no problems and it does NOT have ECC correction.
As for 64 bitness, the benefit in floating point calcs will be about nil,
but 64 bit integer operations will be much faster due to being able to do
integer math in a register instead of several consecutive operations. Think
about ordinary things, for example integer mult, add, sub, cmp and mov -
all of those will be able to do 64 bits at once instead of 32. If you can
take advantage of that then you will see a performance increase. Where 64
bit systems also shine is in the ability to directly access a very large
memory space.
Eric
--
In the 2004 election King County found "missing ballots" 9 times
Each time, in response to vote counts they didnt like
Can you say FRAUD?

On Thu, 03 Feb 2005 20:41:18 -0800, Eric
<(E-Mail Removed)> wrote:

>Bob Day wrote:
>
>> "Arnab Chowdry" <(E-Mail Removed)> wrote in message
>> news:ctpkcp$g22$(E-Mail Removed)...
>>> Hello all,
>>>
>>> I am assembling a cluster for some computational work. I have to make the
>>> hardware choice between traditional 32-bit systems and the newer 64-bit
>>> systems that have recently been released by AMD and Intel.
>>>
>>> The programs that will be running are very math-heavy and use double
>>> precision floats (generally assumed to be 64 bits of information). The
>>> question I have is: while the 64-bit architecture is sexy, does it
>>> actually provide a performance gain? Would a 64-bit processor multiply
>>> two doubles twice as fast as a 32-bit processor?
>>
>> Since you are planning to some very math heavy computation,
>> you might want to consider a system with the highest data
>> integrity, i.e., the having the least chance of your results getting
>> corrupted because of memory errors occurring during computation.
>> Memory is the weakest link in a standard PC configuration with
>> respect to data integrity. According to a white paper published in
>> January 2004 by Tezzaron Semiconductor, a PC with 512MB of
>> memory running 24 hours a day will sustain a memory error about
>> every 10 days. (Reference:
>> http://www.tezzaron.com/about/papers...1%20secure.pdf
>> See Appendix B, Calculations, on page 6).
>>
>> For the highest memory integrity for a reasonable price, consider an
>> Opteron CPU, an ASUS SK8V mainboard, and -x4 bitwidth memory
>> modules such as Crucial CT6472Y335.18LFC4. This configuration
>> will give you an advanced form of ECC known as "Chipkill".
>>
>> -- Bob Day
>> http://bobday.vze.com
>
>That may be true "on paper" but in reality its a myth. For example,
>I've got a system thats been running 24/7 for 125 days now with absolutely
>no problems and it does NOT have ECC correction.

You mean absolutely no _observed_ problems. It is easy to
ignore errors when they don't surface, aren't obviously
effecting crucial data... or maybe they are but there is no
safeguard to check this.

In reality the myth is that the errors don't occur. Unless
your systems are deep in a cave somewhere, you can do
nothing to prevent the errors, they ARE happening even in
the theoretically perfect system (except without ECC
memory).

Eric wrote:
>
.... snip ...
>
> That may be true "on paper" but in reality its a myth. For example,
> I've got a system thats been running 24/7 for 125 days now with
> absolutely no problems and it does NOT have ECC correction.

That's "no problems THAT YOU KNOW OF". Was any bit flipped in the
process of copying or making some file? Are you sure that that
change would have been noticed by now? There have been no cosmic
rays reach your machine in those 125 days, so it must be buried
deep within some mine.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson