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: <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