Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!ames!pioneer.arc.nasa.gov!lamaster From: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) Newsgroups: comp.arch Subject: Re: 64 bit addresses Message-ID: <1991Feb13.212041.14368@news.arc.nasa.gov> Date: 13 Feb 91 21:20:41 GMT References: Sender: usenet@news.arc.nasa.gov (USENET Administration) Reply-To: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) Organization: NASA Ames Res. Ctr. Mtn Vw CA 94035 Lines: 96 In article mh2f+@andrew.cmu.edu (Mark Hahn) writes: >Just think of the added overhead in pointer-linked structures! I tried to think of it, and failed! Several posters have mentioned this. At the end of every chain of pointers, there must be some data there somewhere!? What is the ratio of pointers to other data in typical "small" programs? Would doubling the size of addresses add anything significant, considering the sizes of main memories on current "small" systems (usu. minimum of 8 MB)? (The Cyber 205 used to have 64 bit "addresses" (actually descriptors). Regardless of whatever other problems the machine had, the addresses were not a problem. I note that, though, it only had to do integer arithmetic on 48 bits of the address, not 64.) Caches *could* be a problem, since the contents of caches *might* be more address intensive than main memory. Does anyone have any *data* that shows that this is a problem? I *know* it isn't a problem for typical scientific/ engineering code, but I'm not sure about pointer-intensive object oriented stuff... >Big addresses are a major win for typed support though, since (deleted text) > ..... I guess the whole point is to make large, >sparse structures feasible, since it doesn't seem realistic >to do _anything_ in 64bit (~2e19) quantities: Large sparse structures are *one* of the benefits to "large" addresses, which we will enjoy for the next few years. Until what year? The way I look at it (historically), we will *run out* of address bits to address physical memories somewhere between 2010 and 2020, using 64 bit addresses. Then, we will be talking about 128 bit addresses, and how extravagant they are, and how the only use for them will be large sparse structures. 1/2 :-) Of course, we have *already* run out of bits in 32 bit addresses. Obviously! :-) >RAM: 1M simms @ $50 5e1/1e6 $1e15 >hard disk 1.2G @ $3k 3e3/1e9 $6e13 >gigabit net or >fast memory bus 1/1e8 2e11 sec (millennia) > >On the other hand, 32bits (~4e9) is just $2e5 RAM, $1e4 disk, 40 sec. >On the first hand again, perhaps CS needs a superproject, too! Looking in my IBM Systems and Products guide (1 year old - early 1990 edition) I find that models of the ES/3090 were (then) sporting 512 MBytes of main memory, 2 GBytes of extended memory, 128 4.5 MB/sec channels, and multi-disk/head storage units with 3.78 GB/head (memory mapped I/O, anyone?) Off the shelf Computer Science Department workstation servers from various vendors already have >= 128 MB of real memory. Ordinary mass production disk drives are in the 1-2 GByte range (in case you might have an application which needs memory mapped I/O on a large file :-). You can buy compatible RAID disk products for some systems with something like 15 MB/sec throughput... To put it another way, it won't just be a "superproject" that will need > 32 bit addressing in the next few years. My congratulations to MIPSCo for facing up to this problem, even though, no doubt, it will be a public relations flop with the same people who were telling us that we didn't need > 16 bit addresses a few years ago, since anything bigger than that was just evidence of "wasteful" programming. Actually, I take it back. Some of them are *still* saying it :-) I argue on historical grounds that it would be counterproductive to extend addresses to, say, 40 bits, in order to save a few bytes per address, to last until the year 1999. In 2000, you will have to do it all over again. And, a lot of data paths are now already 64 bits wide, anyway, so that isn't a problem. The CDC approach: use 48 bits, and do something else with the other 16 has *something* to recommend it. But, I don't. 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. The only *potential* problem that I can see is that with 64 bit addresses, you need a 1 cycle 64 bit integer adder, which is no mean feat, as far as I know. The largest linear address I have previously seen is the aforementioned 48 bits. Also, with less than 64 bit addresses, you must, in the meantime, deal with the hassles of non-power-of-two address sizes. And, with the size of int not equal to the size of a pointer (which isn't a problem with *my* code, but it might be with *yours* :-) ) And, forgo the benefits of enjoying a large, sparse, address space for the next *few* years... :-) Hugh LaMaster, M/S 233-9, UUCP: ames!lamaster NASA Ames Research Center Internet: lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 With Good Mailer: lamaster@george.arc.nasa.gov Phone: 415/604-6117