Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!rutgers!labrea!decwrl!pyramid!prls!weaver From: weaver@prls.UUCP (Michael Gordon Weaver) Newsgroups: comp.arch Subject: Re: The 360 was a design landmark (360 vs vax) Message-ID: <5847@prls.UUCP> Date: Thu, 27-Aug-87 13:51:46 EDT Article-I.D.: prls.5847 Posted: Thu Aug 27 13:51:46 1987 Date-Received: Sat, 29-Aug-87 13:00:29 EDT References: <855@tjalk.cs.vu.nl> <2683@hoptoad.uucp> <916@haddock.ISC.COM> <418@astroatc.UUCP> <26444@sun.uucp> <2595@ames.arpa> Reply-To: weaver@prls.UUCP (Michael Gordon Weaver) Organization: Signetics Microprocessor Division Lines: 37 In article <2595@ames.arpa> lamaster@ames.UUCP (Hugh LaMaster) writes: >.... As was previously noted, a good compiler >can produce rather dense code for the VAX. The 64,000 MIPS question is: how >important is that? Was it ever that important? If memory utilization was >that important even in 1977, why didn't the paging hardware support direct >LRU? DEC's success with the VAX was due to the 32 bit virtual memory >environment- a first for minicomputers at the time- not performance or >price/performance. > I believe that the reason that code density was considered so important in the design of the VAX has to do with instruction speed, not memory requirements (disk storage size is a third possible reason). At that time (from what I have read) there appeared to be some consensus that the bottleneck for (non-floating point) instruction throughput was fetching instructions. Today, many people think instruction decoding is a major bottleneck. The VAX 11/780 performs instruction fetch and decode in parallel to arithmetic operations, so in this sense it is similar to RISC-II or MIPS. It has a cache which is probably fast enough not to limit instruction speed, but has miss rate is higher than what we expect today due to its size. The absolute size of code does not vary much (~30%) from one 32 bit machine to another, but the typical instructions cache for a given MIPS rate is perhaps eight times as large today as in 1977. So the frequency of waiting for instructions to be fetched from main memory should be decrease significantly. I do not have any numbers to make this plausible, but my feeling is that this is the best reason for the emphasis on code density. -- Michael Gordon Weaver Usenet: ...pyramid!prls!weaver Signetics Microprocessor Division 811 East Arques Avenue Sunnyvale, California USA 94088-3409 Phone: (408) 991-3450