🚀 go-pugleaf

In <44d1n3$6tn@murrow.corp.sgi.com>, mash@mash.engr.sgi.com (John R. Mashey) writes:
>In article <44boso$ies@dg-rtp.dg.com>, kahn@romulus.rtp.dg.com (Opher Kahn) writes:
>
>|> >architecture for the next 30 years, i'd make it clear that it's really 64-bit,
>|>               ^^^^^^^^^^^^^^^^^^^^^^
>|> Well, I would be careful about such statements.  It was MUCH LESS than 30
>|> years ago that people thought that 16 bits was a lot and 32 bits was more than
>|> we would need this century.
>
>Let's try a more detailed analysis, I've posted something like this before,
>but forgot to save it, so let me try again:
>PHYSICAL ADDRESSING
>1) For many years DRAM gets 4X larger every 3 years, or 2 bits/3 years.

This is of course dangerous territory because, to date, everyone that has 
predicted some slowing in the rate of growth has had criticism heaped upon 
their head for being stupid and short-sighted, but I think at some point we 
must admit that the kind of growth we have been seeing cannot continue 
indefinately. We will eventuall run out of atoms. Physics will increasingly limit
our ability to get smaller and faster. For the last 30 years the impediments
to smaller and faster storage were technological, now they are starting to
become physical.

>2) Thus, a CPU family intended to address higher-end systems will typically
>add 2 more bits of *physical address* every 3 years, and will typically
>be sized to fit the *largest* machine you intend to be built.
>Given the normal progress, and usual need to cover 2-3 generations of
>DRAMs, depending on timing of products, you need at least a 4:1 range,
>and maybe a 16:1 range for extreme cases.

It is unclear that our abilities to realize very large systems are growing at the 
same rate as smaller systems. So while average program size may be growing 
at the stated rate, this does not mean that the programs that are actually
pushing on the address space limits are growing at the same rate.

>VIRTUAL ADDRESSING
>1) Is visible to user-level code, unlike physical addresses, which usually
>are not.
>
>2)  I've claimed that one rule of thumb says that there are practical
>programs whose virtual memory use is 4X the physical memory size.  (I.e.,
>having seen some like this ... and seeing that if they start paging much more,
>they get slower than peopel can standa :-).  Hennessy claims this is
>a drastic under-estimate, i.e., that as memory-mapped files get more use,
>and files-with-holes, one can consume virtual memory much faster ...
>and I agree, but it is hard to estiamte this effect.

I used to be a BIG advocate of mapping file systems into virtual memory
memory systems (based on the unified access mechanism argument). This 
no longer seems so attractive, particularly with so much remote file system
access. Virtual mapping of files while sometimes interesting, is certainly not
necessary (the right API could easily provide what looked like random file
access without file mapping), and if supporting file mapping is going to push
word width past 32 bits, maybe we should delay it for a while.

>FORECASTS for 64->128-bit transition:

64 bit addresses allow approximately 4GBytes of address range per human
inhabitant of the planet. It is unclear how many people the planet can
contain, but even allowing for a 4 fold increase in population density, it
seems questionable why a single machine's address space would need to 
be able to hold an average of 64,000,000,000,000,000,000,000,000,000 bytes
per planet inhabitant. This is more than enough space to keep track of
everything a person sees and hears with millesecond resolution for their
entire life.


I think the 64-bit transition is one that brings little to no real value. It will 
increase code and data size with very little return in terms of performance.
I have been measuring program size for the last 6 years on every system 
I encounter, looking for the largest executables. This includes a broad
range of systems from mainframes to PC's. What I have found is that the
largest executable on what seems to be a typical system does not have 
more than a dozen megabytes of executable code. I have seen no
appreciable change in this size over the last few years.

I have also measured maximum file sizes, ignoring the files generated by
databases that like to keep everything in just one file. While average file
size is relatively small, maximum file size has, in my experience, broken
into the 100 megabyte range. Discussions with some friends in the text
retrieval business has indicated that individual GB size files are sometimes 
useful, but that larger logical data stores are more, or just as, easily 
handled by some arbitrary partitioning into sub GB files. I do not doubt that
there are some limited number of applications and users that have needs
that transcend the 32-bit addressing boundary, I just do not think this is the
general case. 

Patterson and Hennesey indicate that when address bits become tight, 
someone always comes up with some hair-brained segmentation solution
to extend a limited address range when a simple increase in address
size is what is really necessary. Not wanting to pass up an opportunity to
be hair-brained I decided to invent a 32-bit segmentation scheme to solve 
the address range problem and what I concluded was that 32 bits provides
significantly more in the way segmentation possibilities than perhaps people
give it credit for and I think a 32-bit segmentation scheme could satisfy
addressing needs for the next 15-20 years.

david mayhew, ibm, (919)-254-4351