Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!vsi1!wyse!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: Don't look back Message-ID: <13849@winchester.mips.COM> Date: 24 Feb 89 22:52:18 GMT References: <13582@winchester.mips.COM> <20667@lll-winken.LLNL.GOV> <7330@pyr.gatech.EDU> <656@m3.mfci.UUCP> <20821@lll-winken.LLNL.GOV> <665@m3.mfci.UUCP> Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 109 In article <665@m3.mfci.UUCP> colwell@mfci.UUCP (Robert Colwell) writes: ...... >I hope you mean that there will be some micro somewhere in a system >that achieves a higher throughput on a scalar program, because anything >else doesn't count. And there, I further predict that said micro, >having achieved this feat, will then have trouble on one of two other >counts -- having enough physical memory present to handle the same >size jobs that people want, having enough flops to not be embarrassing >on more vectorizable codes, and having enough I/O to support all of the >above without making the user smash the keyboard in frustration. And >all of that at workstation prices. If you go higher in the cost space, >then your one-chip solution must start competing with multi-chip solutions >that have much more flexibility in their implementation. And as I've >argued before, they don't pay all that much a penalty for it either, >because systems at these performance levels put most of the implementation >dollars into memory and I/O, not CPU. I agree 100% with Robert on the issue of building balanced systems: it's important. I also don't expect widely-available workstations to give supers or minisupers a hard time any tiome soon. [Why? WHen you look at the tradeoffs you tend to make for the volume workstations, you tend to limit them in terms of memory size, I/O, and expandability. Of course, one's idea of workstation certainly goes up over the years.] Workstations are not small servers/minicomputers, which are not large servers/big superminis/small mainframes, which are not big mainframes or mini-supers, which are not supercomputers. On the other hand, you can take the same chips that you might use in a very unbalanced workstation [i.e., lots of CPU, and less I/O], and build fairly powerful, balanced machines with the same technology, and save a tremendous amount of moeny across a product line, even though, in the largest machines, the CPU chips themselves are basically almost free. In the small machines, you may well waste CPU power to lower cost, and not have smart peripheral controllers, etc. In the bigger ones, you may have multiple CPUs, smart controllers, high-powered backplanes, etc, etc. A good example that can be seen right now is the way DEC uses it CMOS VAX chips in different configurations, and I have to believe that it really helps their overall product line costs. The second issue is a more subtle one, which is, that as the volume goes up, the unit costs go down, and this can be seen in the I/O area as well. In particular, cheap things that you wished would exist don't come into being until the systems that want them make sense. Let me give a few examples, observing first, that in the Old Days, if you built computers, it meant you built everything yourself, CPUs, memories, disks, tapes, etc, etc, and if you couldn't do it, you weren't in the business. That's changed a lot; only the largest companies can afford to, and even they do a lot of judicious outsourcing. Now, you can put together some pretty good machines by integrating a lot of other people's work: a) Remember when having an Ethernet controller meant you had a good-sized board full of logic? If the only systems that wanted Ethernet were large superminis, you might not have LANCE chips at reasonable costs. [Why would anybody bother to build them if there weren't going to be volume?] b) SCSI controllers: same thing. c) Very fast 5 1/4" (or 3 1/2") disks: why would you want these if all you had were mainframes [which want huge fast disks], or PCs [which started wanting small cheap disks]. On the other hand, with workstations and fast supermicros, you can get real use from these things, which raises the volume, which drops the price, and makes it worth investing the effort to make them faster. The best of these compete well with ESMDs on some speed metrics, and now people are looking real hard at building big, fast, cheap, disk substystems out of arrays of these (like the UCB work, as just one example). d) High-speed controller boards: people like Interphase build some pretty fast controller boards. Who uses them? People who have 1) fast CPUs 2) nonproprietary I/O busses People who have slow CPUs naturally choose lower-performance controllers. People who have proprietary I/O busses spend a lot of money building their I/O systems (and sometimes, necessarily so to get performance they want, or, perhaps, redundancy or other special functionality.). But look what happens when you get cheap, fast CPUs in systems that use industry busses. All of a sudden there's a market there for somebody who wants to supply controllers, and there might be enough volume to justify the effort, and although the high-performance controllers might command a premium price, the costs of these boards are much less than the corresponding costs of more proprietary ones, if the latter must be engineered for lower-volume products, even in the same performance range. What you see is a pattern: a) People will build high-performance I/O products, if there are systems they make sense in, and the costs will go down. b) If cheap CPUs keep getting faster, there will be more pressure to boost the I/O performance (cheaply), and that creates markets for people doing higher-integration-level VLSI to fill the demand. So that brings us back to the original discussion: if you build systems out of the same (or a small number of different, like CMOS & ECL) VLSI CPUs, the lower part of a product range gets drastic percentage savings [a large board or two less is serious business], the middle can take the cost savings and put some of it in I/O, and the top gets the benefit of spending little engineering effort on the CPU, and can take that effort and also put it into I/O. Maybe all of this gets enough volume that people can say "we should have a super-whizzy bus chip, and we can now afford to build it." (There are more words than I like in this, and I'm not sure I've communicated the industry-interaction effects as well as I'd like, so maybe somebody else can say it better.) -- -john mashey DISCLAIMER: UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086