[Beowulf] Moores Law is dying

[Robert G. Brown]

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
> jlforrest at berkeley.edu
> _______________________________________________
> Beowulf mailing list, Beowulf at 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:rgb at phy.duke.edu