🚀 go-pugleaf

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.

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.

For example, 36-bit physical addresses support 16GB memories ...
and there already have been shipped single-rack microprocessor boxes with
16GB using just 16Mb DRAMs; there are of course, more in the 4GB-8GB range.
Of course, a 32-bit physical addressingmachine can get around this with extra
external-mapping registers ... assuming one can ignore the moaning from
the kernel programmers :-)


Of course, some kinds of system designs burn physical memory addresses
faster than you'd expect.   In particular, suppose you build a system
with multiple memory systems.  A minimal/natural approach is to use the
high-order bits of an address to select the memory to be accessed.
The simplest design ends up leaving addressing space for the *largest*
individual memory, so that smaller memories leave addressing holes.
I.e., suppose each memory might range from 64MB to 1GB (30 bits).
With a 36-bit address, one can conveniently use 2**6 or 64 CPUs
together.   Of course, if individual memories might go to 4GB (factor of 4),
then you are now down to 16 CPUs.

Note: of the next crop of chips, the physical address sizes seem split
between 36 and 40 bits...

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.

FORECASTS for 64->128-bit transition:
1) If memory density continues to increase at the same rate,
and virtual memory pressure retains the 4:1 ratio, and we think we've just
added 32 more bits, to be consumed 2 bits/3 years, we get:
	3*32/2 = 48 years
and I arbitrarily pick 1995 as a year when:
	a) There was noticable pressure from some customers for 4GB+
	physical memories, and a few people buying more, in "vanilla"
	systems.
	b) One can expect 4 vendors to be shipping 64-bit chips,
	i.e., not a a complete oddity.
Hence, one estimate would be 1995+48 = 2043 to be in leading edge of
64->128-bit transition, based on *physical memory* pressure.
That is: the pressure comes from the wish to conveniently address the
memory that one might actually buy.

Of course, the multiple-memory system issue above pulls that in a few
years ... however, one can deal with that in the time-hallowed way of adding
extra mapping information, without bothering user-level code with changes.

2) On the other hand, if files-with-holes and file-mapping of large
files get much heavier use, the *virtual memory* pressure grows much faster
than a constant factor above the physical size ... and my best guess yields
around 2020.  Note that "minor" implementation issues like die space,
routing, and gate delays, especially of 128-bit adders & shifters are
non-trivial, so people aren't going to rush out and build 128-bitters for
fun, just as people matched timing dates of their 64-bitters to their
expected markets.  Of course, if somebody does an operating system that
uses 128-bit addressing to address every byte in the world uniquely, *and* this
takes over the world, it might be an impetus for 128-bitters :-)

Of course, all sorts of surprises could occur to disrupt these scenarios.
Note however, that the common assumption that it took N years to go
from 32->64 means that it would take N years from 64->128 ... is
incompatible with the normal memory progress, i.e., 64->128 is 2N.


-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    mash@sgi.com 
DDD:    415-390-3090	FAX: 415-967-8496
USPS:   Silicon Graphics 6L-005, 2011 N. Shoreline Blvd, Mountain View, CA 94039-7311