Path: utzoo!attcan!uunet!lll-winken!ames!elroy!cit-vax!cataract!fritz From: fritz@cataract.caltech.edu (Fritz Nordby) Newsgroups: comp.arch Subject: Re: 64 bits Message-ID: <9119@cit-vax.Caltech.Edu> Date: 16 Jan 89 04:49:26 GMT References: <28200249@mcdurb> <28200260@mcdurb> Sender: news@cit-vax.Caltech.Edu Reply-To: fritz@cataract.UUCP () Organization: California Institute of Technology Lines: 72 In article <28200260@mcdurb> aglew@mcdurb.Urbana.Gould.COM writes: > >>/* Written 7:45 am Dec 16, 1988 by mac3n@babbage.acc.virginia.edu in mcdurb:comp.arch */ >>> It's long past time that computer systems - compilers and/or >>> ALUs - supported >32 bit integers. 64 bits here we come! >> >>uh... would 36 hold you for a few days? >>and how about running out of characters at 256? >>/* End of text from mcdurb:comp.arch */ > >I just saw an ad for a data vault for a VAX that holds 4-8G. >Given the "3 bits per year" rule of thumb, 36 bits for disk >will be passed soon (if you do the "right thing" and make the disk >an array of bytes - I know, I know, this isn't what's done. But it >should be). > >Of course, banks have had terabytes of data for years now. "3 bits per year"? Where do you get that idea? That's a lot faster than memories or memory usage is growing. Consider: Semiconductor memory devices are growing at about 2 bits per 3 years ... they've been growing about that fast since the early '70s. This scaling is a combination of device scaling (Mead/Conway "lambda" scaling, roughly) and chip area increases, both of which are roughly exponential processes. User memory demands are (even more roughly) exponential processes as well. The best information I have on this is from a CACM article: "Case Study: IBM's System/360-370 Architecture" (CACM, vol. 30, no. 4 (April 1987), pp. 291-307). This article is an interview with Richard Case and Andris Padegs, "two of the key people responsible for the 360/370 architecture ...." In the published interview (p.305), Case states (AS is one of the interviewers): Case: .... The reason we needed the System/360 in the early 1960s was for its 24-bit address space. That was enough for a decade, and then we had to expand to 31 bits. We had laid the groundwork for that back in 1964. At present we are using up one bit of address space every 30 months. That means we are going to eventually reach the point where a 31-bit address space is insufficient. For a while we'll be able to get by with a collection of patches and switches, but they will not last forever. Probably by the time we need 34 bits or so there will have to be another major upheval. AS: I presume that XA came out just in the nick of time in 1983. Case: It was late. Some customers could have taken advantage of it earlier. AS: Okay, so in several years you will run out of 31 bits. You have a couple more bits you said you could handle by ad hoc means. So you've got until 1995, and then your upheval will occur. Case: It's plus or minus a couple of years, at today's rates. Now whether today's rates continue, or whether something else will happen, I don't know. But addressing is the most important driving force in instruction-set architecture. Note that this is about the same as the scalings of memory configurations for the Cray and VAX processor lines over the 1977-1988 period. So, 2 bits per 5 years seems a reasonable estimate of how user memory requirements grow. Note that chip capacities are growing faster than system memory requirements. Over a 15 year time span, this says that we will need 6 bits more memory (for the user), and we'll have 10 more bits of addressing per chip; thus about every 4 years, memory systems halve the number of chips they use. What does this mean? Well, since memories all seem to be the same width, this means that the von Neumann bottleneck is getting narrower and narrower, at least in scaled terms (i.e., scaled by processor speed): witness the growing importance of cacheing to system performance in aggressive designs. Fritz Nordby. fritz@vlsi.caltech.edu cit-vax!cit-vlsi!fritz