Newsgroups: comp.arch
Path: utzoo!utgpu!watserv1!watdragon!watsol.waterloo.edu!tbray
From: tbray@watsol.waterloo.edu (Tim Bray)
Subject: Re: 64 bit addresses
Message-ID: <1991Feb14.183045.16468@watdragon.waterloo.edu>
Sender: daemon@watdragon.waterloo.edu (Owner of Many System Processes)
Organization: University of Waterloo
References: <cbiAekK00VpINR8nEq@andrew.cmu.edu> <1991Feb13.212041.14368@news.arc.nasa.gov>
Date: Thu, 14 Feb 1991 18:30:45 GMT
Lines: 55

lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes:
>mh2f+@andrew.cmu.edu (Mark Hahn) writes:
>>Just think of the added overhead in pointer-linked structures!
>
>What is the ratio of pointers to other data in typical "small" programs?  

Well, the two application domains I've been involved with in the last 5 years
or so are: (1) Symbolic algebra systems, and (2) Text databases.  In the case
of these programs, you tend to find relatively small tight kernels [see PS]
and massive data structures, which are *very* pointer-dense.  At least 50% in
both cases, probably more on average, especially the text database stuff.

Now both of these application domains are starting to crunch into 32-bit
boundaries on non-exotic real-world problems, so the extra addressing bits
will be extremely welcome.  The price will be a dramatic increase in physical 
memory consumption.

Which is maybe (retch) a good trade-off.

Two questions:
 o as a software developer currently bruising my head against 32-bit issues, 
   should I: 
   (1) bite the bullet and write a segmented scheme which will run 
       portably (if suboptimally) on 32-bit systems, or 
   (2) sit tight and wait for rescue-by-recompilation on the R4000 et al?  

   At this point, economics may favour (1) (retch again).

 o a lot of important software has, for a lot of years, cheated and stolen
   a few bits from 32-bit words for tags and typing and so on.  This
   can produce some *really* elegant effects and allow a lot of data 
   manipulation with efficient integer instructions.  While this should be
   unportable, such software has in fact been widely ported, albeit with
   some pain.  With native 64-bit integer primitives, the temptation to cheat
   and steal (as much as a byte's worth) of tag bits and so on will become
   very great again.  C'mon, that leaves ***56 bits***!!! Particularly given 
   the memory growth noted in the point above.  Commentary?

Hugh LaMaster's view on this:
>Better to waste
>another whole 64 bit word on other stuff if necessary, than to create such
>complications.   8 Bytes is just not that precious anymore.  Only if you
>have arrays of millions of objects should you compromise on simplicity.

But we do, sigh, lots of us do.

Cheers, Tim Bray, Open Text Systems, Waterloo, Ontario

[PS] Here's the output of size(1) on the Maple (symbolic algebra) and Pat (text 
search) kernels.  Both of these programs can blow your memory away effortlessly
with data structures, given a really large problem.  (SPARC binaries)

text	data	bss	dec	hex
393216	57344	13632	464192	71540  maple
204800	16384	576	221760	36240  pat
