On Tue, 14 Apr 2009, Jon Forrest wrote:
The reason for this is that it's simply too hard to write
a program whose instructions require even close to the
32 bit address space. Such a program would be too complex
to understand, assuming it's written by humans. Maybe
I'm not sure what you mean here. Surely the instructions are in all
cases built into the final list by a compiler (linker/loader). Are you
suggesting that e.g. a long-running program with fully unrolled loops
cannot exceed 4 GB in size and still be "simple"? Are you suggesting
that compilers will never try to unroll code at that level, even when
enormous memory systems are commonplace? Are you suggesting that even
when concatenated, the space of all possibly functional operational
phonemes in computational semantics cannot fill a 4 GB dictionary?
such a program could be generated by a program, but
I'm not talking about this.
Such a program could EASILY be generated by a program -- the compiler,
with simple tradeoffs between looping and e.g. subroutine jumps vs
inlined instructions.
Another such program is "the operating system" especially a multitasking
operating system. There is no real bound on the number of threads an
operating system can run, and "the program" being run on a multitasking
operating system is the union of all "sub" programs being run on the
system, with or without shared libraries (sharing is expensive in
performance, remember -- we do it to save memory because it is a scarce
resource). Clearly that can and does exceed 4 GB, even routinely on a
heavily loaded server and we'd do it a lot more often without shared
libraries. This isn't really programs being generated by a program
(although of course the programs were compiled) - it is simply the union
of a lot of code written by humans. It is, in aggregate "too complex
for humans to understand" in one sense -- and yet quite straightforward
in another.
I once added up the text segment of every executable
and shared library on a Linux system. I probably counted
some files more than once. Even so, the total text size
of all these files was less than 2GB.
And I'm not really arguing -- 4 GB is a lot of room, especially with
shared libraries and reuse of code. However, both complexity and
tradeoffs between performance and length of code CAN put a lot of
demands on memory, ones that we routinely do NOT make now because there
IS a fundamental scarcity there that has only barely started to progress
beyond the 32 bit limit. Ask me again when 128 GB and up systems are
commonplace. I predict that at that point there may well be a lot of
code that expands to more than 32 bits worth of space for reasons of
sheer performance. And there MAY be new compilers that are a lot more
generous in their usage of space than they are now. There may be
new-gen RISC-y processors that use far more instructions to do things
that are currently done with fewer ones. Is your observation
Intel-arch-only?
rgb
I'm not proposing doing anything about this, such
as coming out with an architecture that uses
32-bit text pointers and 64-bit data pointers.
That would add needless complexity. But, it's important
to realize that this limit exists, and unless
we get much smarter, isn't likely to go away.
Cordially,
--
Jon Forrest
Research Computing Support
College of Chemistry
173 Tan Hall
University of California Berkeley
Berkeley, CA
94720-1460
510-643-1032
jlforr...@berkeley.edu
_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
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:r...@phy.duke.edu
_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
