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

[Jon Forrest]

Robert G. Brown wrote:

> I totally agree with Joe on this issue.  The "ideal" computer would have
> an infinite, flat address space, totally transparent to the user.  Want
> to address memory location FF 0A BB 79 C3 12 93 54 6A 19 1D DA? (or
> simply have 2^90 \approx 10^27 data objects to manage)?  The memory
> should be there, flat, transparent.

I agree completely.

> I don't understand how you could possibly imagine this to be true.  I do
> numerical spin simulations on lattices in D dimensions.  An
> N-dimensional spin (where N is not necessarily equal to D) is typically
> represented by 1-(N-1) real numbers (e.g. spherical polar angles).  In
> addition any give spin may have other internal coordinates.  To
> represent a spin therefore requires minimally order 4*N bytes for an
> ordinary 32-bit float representation of the spin coordinates, more
> likely 8*N bytes if one sensibly uses double precision coordinates.  For
> 3D spins say 24 bytes per site.
[]
> 
> This isn't an isolated (if specific) example.  There is a vast range of
> memory-size bound problems, some of which have modest CPU requirements
> but an absolute necessity to be able to efficiently address large memory
> spaces.  

The examples you give are very good reasons why there is
a clear need for more than 32-bits of address space for
data. Again, I agree completely. But, if you read my original
posting, this is not what I'm talking about. I'm talking
about the need for more than 32-bits of address space for
instructions (a.k.a "text"). Why don't you run the "size"
command on any of your big programs and report back what
you find. My guess is that they'll be in the order
of 10s of megabytes. (I agree that this method doesn't
show the true run-time text-size requirements but
it's a good first attempt).

> Personally I "wish" that they'd done the dual core thing entirely
> differently.  Instead of having two completely independent 64 bit cores
> per CPU, they might have built a 128-bit core with a hardware floating
> point execution pathway that permitted it to be transparently broken
> down into 4 32 bit parallel pathways, 2 64 bit pathways, 1 96 bit and 1
> 32 bit pathway, or 1 128 bit pathway, with entirely transparent flat
> memory access out to 128 bits, and with hardware implementation of 128
> bit integer or 128 bit floating point arithmetic (on down).  Leave it to
> a mix of the CPU, the OS, the compiler, and the application to decide
> how to pipeline and allocate the available ALUs, registers, cache lines,
> etc. to the needs of the program.

Like I've said before, I'm not seriously proposing changing any
existing architectures to have 32-bit text pointers and
64-bit data pointers, along with the corresponding changes
to internal pathways.

> But I'm not terribly worried.  This to some extent describes the cell
> architecture, with some slop as to just where the ganging together of
> smaller logic units into larger ones occurs.  And lots of very smart
> people are working on this -- smarter than me for sure -- and doubtless
> have far better ideas.  Stating that there is no need for 64 bit
> architectures and that 32 bits is enough for anyone is basically
> equivalent to stating "the systems engineers working for AMD and Intel
> and IBM and Motorola are complete idiots".  This is simply not the case.

Again, you misread my original claim.

> they aren't idiots, they are brilliant, and the simple fact of the
> matter is that 64 bit systems are faster, smarter, bigger, better than
> 32 bit systems. 

After some private email exchanges with various list members,
I no longer claim that, in general, there is no speed difference
between a program that fits in 32-bits when it's run in
32-bit mode as compared to being run in 64-bit mode. Instead,
I believe that it would be instructive to run important programs
in both environments to see what comes out.

But I stand firm on my claim that no human, or group
of humans, can write a program that requires more than
32-bits of text space.

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