Jon,<br>
<br>
The size of the final source code for a program is not really relevant
to human comprehension, because we chunk it. FORTRAN makes it possible
for the engineer to comprehend a program that would be inaccessible to
him as the equivalent (very long) list of Assembler statemtents; how
far would you get with the IMSL if you had to inline every byte at the
level of loading registers? And IDEs generate much more code these days
than anyone wants to read. When you use Visual Basic to whip togehter a
UI, which is fun and easy, it generates event handler hooks that
nobody, really nobody, wants to look at. <br>
<br>
During the year that WorldCom tanked I was solely responsible for
maintaining a million lines of legacy stuff. The produce of a team of
Ivy PhD's using automation with proprietary libaries. There were
hundreds of makefiles and build scripts; just compiling the project was
almost too big to comprehend, much less the project itself. Yet one
million lines is much smaller than 2GB :-) But it was comprensible as
chunks, as modules, like you comprehend a map of Europe divided into
countries, not blades of grass. Searching that for memory leaks was a
bear though I can tell you.<br>
<br>
Also, a single (recursive) line of code can be incomprehensible in a
strong sense. Consider the short defintiion of Mandelbrot sets. It
might take a year of Complex Analysis to comprehend the short
definition :-) but nobody can comprehend the result, in a sense. You
can't predict what the resulting image will look like, other than that
it will be pretty, confusing, and self-similar. Recursion is magical.<br>
<br>
I just don't think there is anything special about 32-bit addressing.
CAD/CAM type methods, applied to software itself; the von Neuman
architecure of the code segment being equivalent to the data segment;
not to mention the potential of AI regenerating itself; makes any
specific limit of code size difficult to imagine, for me.<br>
<br>
That said, I can imagine it will be /would be/ maybe already is
somewhere, cool for a many-core design to be hierarchical; if you have
a zillion cores on a chip, imagine 8 8-bit ALUs along side one 64-bit
CPU, for vector processing of small integers, and each might quickly
address it's own little chunk of 256 bytes of cache.<br>
<br>
Peter<br><br><div><span class="gmail_quote">On 4/14/09, <b class="gmail_sendername">Jon Forrest</b> <<a href="mailto:jlforrest@berkeley.edu">jlforrest@berkeley.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<span class="q">Joe Landman wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
We know of (and have worked with) many applications that have required
tremendous memory footprint.  One that required hundreds of GB of
ram in the late 90s might use a bit more today.<br>
</blockquote>
<br></span>
I claim that there's a memory-related constant that hasn't been<br>
widely recognized. This is that the amount of address space for<br>
a program's text segment will never exceed 32 bits. Note that<br>
I am *not* talking about the data segment.<br>
<br>
The reason for this is that it's simply too hard to write<br>
a program whose instructions require even close to the<br>
32 bit address space. Such a program would be too complex<br>
to understand, assuming it's written by humans. Maybe<br>
such a program could be generated by a program, but<br>
I'm not talking about this.<br>
<br>
I once added up the text segment of every executable<br>
and shared library on a Linux system. I probably counted<br>
some files more than once. Even so, the total text size<br>
of all these files was less than 2GB.<br>
<br>
I'm not proposing doing anything about this, such<br>
as coming out with an architecture that uses<br>
32-bit text pointers and 64-bit data pointers.<br>
That would add needless complexity. But, it's important<br>
to realize that this limit exists, and unless<br>
we get much smarter, isn't likely to go away.<br>
<br>
Cordially,<br>
-- <br>
Jon Forrest<br>
Research Computing Support<br>
College of Chemistry<br>
173 Tan Hall<br>
University of California Berkeley<br>
Berkeley, CA<br>
94720-1460<br>
510-643-1032<br>
<a href="mailto:jlforrest@berkeley.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">jlforrest@berkeley.edu</a><div><span class="e" id="q_120a5c95ade7fbc9_2"><br>
_______________________________________________<br>
Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Beowulf@beowulf.org</a> sponsored by Penguin Computing<br>
To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>

</span></div></blockquote></div><br>