Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!crdos1!davidsen From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) Newsgroups: comp.arch Subject: Re: Segmented Architectures ( formerly Re: 48-bit computers) Message-ID: <3336@crdos1.crd.ge.COM> Date: 12 Apr 91 21:15:59 GMT References: <1991Apr04.023845.3501@kithrup.COM> <1991Apr6.211320.18594@athena.mit.edu> <7YKAMBE@xds13.ferranti.com> <1991Apr12.021609.5340@athena.mit.edu> <24004@as0c.sei.cmu.edu> Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen) Organization: GE Corp R&D Center, Schenectady NY Lines: 56 In article <24004@as0c.sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes: | So, if memory cost drops at 2^8 per decade, it will be as cheap | to fill 32 bits in 1995 as it was to fill 16 bits in 1975. Now, | cheapness isn't everything, but the figure does suggest that, by | 1995, we'll be hitting the 32-bit limit in the same way that we | were hitting the 16-bit limit in 1975. I believe you're basing that on a false assumption that problems grow to fit the available computer, while the truth is that larger computers attract larger problems, which isn't the same thing at all. The subtle difference is that the little problems don't go away. We still have a need for the bc or hand calculator size solution. We still do email and spreadsheets, text editing, and compilations. What this means is that a computer twice as big won't solve twice as many problems. Electronic mail on a SPARC doesn't take more resources than it did on a PDP-11. You can't even put N times as many people doing mail on a machine N times faster, because the i/o hasn't grown N times. What you see is that additional resources don't proportionally solve additional problems, so the cost of solving is larger on a "per problem" basis. Most problems solved on workstations today probably will benefit from faster i/o, and from faster CPU, but not from more memory, because the typical workstation will already handle today's problems. Most workstations are capable of holding more physical memory than they have, say 64MB max, 16MB typical. Given this, if you were a vendor, would you put your R&D into faster CPU or adding memory. And given that a larger word size is inherently slower, would you go to a huge word size for which there was a very limited market? I predict that the growth in the next decade will be in faster CPU, bigger and faster disk, and that the slope of the growth curve in actual memory will be 4x lower than the CPU. Money will be spent on the most marketable solutions, and volume sales will bring price down ... feedback between financial and technical. I think the jump to 64 bit will be limited to the top end of the market, while lots of vendors take advantage of 32 bit being smaller, cheaper, lower power, and faster. And most structs and arrays will be twice as big in 64 bit, driving the cost of 64 bit systems up relative to 32 bit. People who need 64 bit will jump. People who always need the latest may or may not, depending on the speed difference between the 32 and 64 bit machines. The average user would like one, but doesn't have a single problem which needs it. I will guess 64 bit will get less than half the market (by unit) through the end of the decade. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "Most of the VAX instructions are in microcode, but halt and no-op are in hardware for efficiency"