[Beowulf] Win64 Clusters!!!!!!!!!!!!

[Jon Forrest]

Joe Landman wrote:

> No.  The extra registers make compiler optimization work better (lower
> register pressure).  The flat memory model (doing away with segmented
> registers) simplifies addressing, and reduces the work of the processor
> for every physical address calculation (no more segment + offset
> operations to perform *before* pushing out the address onto the wires).

Right. I was talking about the difference in running an application
that fits in 32-bits in a 64-bit environment. There's a flat memory
when it runs this way, or when it runs in a 32-bit environment.

> I would love to see your data for this.  Please note that I have quite a
> bit of data that contradicts this assertion (e.g. directly measured
> performance data, wall clock specifically of identical programs
> compiled to run in 32 and 64 bit mode on the same physical machine,
> running identical input decks).  This is older data, from 2004.  c.f.
> http://www.amd.com/us-en/assets/content_type/DownloadableAssets/dwamd_SI_rlsdWP1.0_.pdf
> but it is still relevant, and specifically, directly addresses the
> assertions.

The tests I made myself were non-HPC, e.g. building large software
packages. But, I'm a reasonable person and I'll be glad to
modify my statement to say that 64-bit computing is oversold
in non-HPC markets. For example, when you look at pretty much
any AMD-based computer these days, and compare it to what
was available ~2 years ago (I'm not sure of the exact date), what
difference do you see on the front panel? You'll see "AMD Athlon"
in both cases, but now you also see "64". On the majority
of computers being sold, this makes no difference. (HPC users
are different). I bet most people think that since 64 is bigger
than 32 then a 64-bit computer is "better". Yet, this isn't the
case for them, especially if they're using a modern version of
Windows, which is what the original posting was about. These days you
also see "X2" which is a different kettle of fish and is, if anything,
being undermarketed.

>> add the additional difficulty of getting 64-bit drivers
>> and what-not, I don't think it's worth messing with 64-bit
>> computing for apps that don't need the address space.
> 
> Which OS are you using?  We haven't had 64 bit driver availability
> issues since late 2004, for Linux.  For windows this may be different.

I agree 100%. I should have been clearer.

>> One additional way 64-bit computing is being oversold
>> is that there aren't now, and maybe never will be, any
>> human written program that requires more than 32 bits
>> for the instruction segment of the program. It's simply
> 
> This is a bold assertion.  Sort of like the "no program will ever use
> more than 640k of memory" made by a computing luminary many moons ago.

Bill Gates says he never said that. In any case, most of that was
due to the architectural inferiority of the x86 at the time.
What I'm talking about is a real limit in the complexity of
what a human, or group of humans, can create. Please name of
piece of software, free or commercial, that needs more
than a 32-bit address space for its instruction space.
As far as I know, there isn't any such thing. Not even close.

>> too complex for a human, or a group of humans, to write
>> this much code. Again, note that this says nothing
> 
> landman at dualcore:~> cat hi.f90
>         program hi
>         print *,"hi"
>         end
> landman at dualcore:~> pgf90 hi.f90
> landman at dualcore:~> ./a.out
>  hi
> landman at dualcore:~> ls -alF a.out
> -rwxr-xr-x 1 landman users 2302794 Apr  8 21:38 a.out*

I just tried the same program on a 64-bit RHEL4-based
release using gfortran 4.1.2. My results are different.
First I compiled hi.f90 with the "-c" option
and got

# size hi.o
    text    data     bss     dec     hex filename
     185       0       0     185      b9 hi.o

After linking it to get an executable I got

# size a.out
    text    data     bss     dec     hex filename
    1893     592       8    2493     9bd a.out

> 2.3 MB for hi.

But I'm not sure what any of this proves, other than
gfortran produces smaller code in this case. I suspect
the difference is in the runtime library that gets
linked in.

>> about the data segment of a program. Also, people tell
>> me that there are programs that were generated by other
>> programs that are larger than 32 bits. I've never seen
>> one, but maybe they exist, and that's what I'm talking
>> about human written programs.
> 
> I am sorry, but I think this may be an artificial strawman.

If so, I don't see it. If my statement is true, that is that
no human written software program will ever outgrow
a 32-bit address space **for text** then that says something
important about what's important and what's not important.
Note that I'm not saying that a modern processor should
be some kind of hybrid mutant with 32-bit text pointers
and 64-bit data pointers. That would be ridiculous.

Cordially,
-- 
Jon Forrest
Unix Computing Support
College of Chemistry
173 Tan Hall
University of California Berkeley
Berkeley, CA
94720-1460
510-643-1032
jlforrest at berkeley.edu