Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!rochester!PT.CS.CMU.EDU!K.GP.CS.CMU.EDU!lindsay From: lindsay@K.GP.CS.CMU.EDU (Donald Lindsay) Newsgroups: comp.arch Subject: Re: Why is SPARC so slow? Message-ID: <524@PT.CS.CMU.EDU> Date: 15 Dec 87 22:07:01 GMT References: <8809@sgi.SGI.COM> <6964@apple.UUCP> <8885@sgi.SGI.COM> <6993@apple.UUCP> Sender: netnews@PT.CS.CMU.EDU Organization: Carnegie-Mellon University, CS/RI Lines: 21 In article <6993@apple.UUCP> bcase@apple.UUCP (Brian Case) writes: >On the other hand, *by definition,* the SUN >approach is more scalable since there is at least some opportunity for >scaling; a fixed-size register file cannot, by definition, be scaled. There is an optimum size for a windowed register-set. The optimum may be hard to locate precisely, but it has to exist. For example, there are programs which don't overflow the window set of current chips. Building chips with more registers, cannot speed those programs up. A more interesting question is, just what makes something scalable ? Sun's answer seems mostly to be "complexity" - they tried to minimize the chip design time so that implementation can track the implementation technology. But, of course, eventually, someone will build a complex implementation, because they had all those gates left over ... and so it goes. Hewlett-Packard just cancelled the project that was building a Spectrum out of ECL. Reportedly they were $20M in. Does anyone know why ? Does this mean anything for the ECL SPARC, or for scalability ? -- Don lindsay@k.gp.cs.cmu.edu CMU Computer Science