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
[EMAIL PROTECTED]
_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
