Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site decwrl.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!dec-rhea!dec-erlang!falcone From: falcone@erlang.DEC (Joe Falcone, HLO2-3/N03, dtn 225-6059) Newsgroups: net.micro.68k Subject: Re: 68020 Performance Revisited Again Message-ID: <4132@decwrl.UUCP> Date: Tue, 6-Nov-84 02:05:08 EST Article-I.D.: decwrl.4132 Posted: Tue Nov 6 02:05:08 1984 Date-Received: Thu, 8-Nov-84 00:52:33 EST Sender: daemon@decwrl.UUCP Organization: DEC Engineering Network Lines: 65 CC: Response to redwood!rbw3 1. Your idea of cpu-intensive UNIX benchmarks sure is strange; Gosh, I always thought there was a fairly large I/O component to cc, nroff, grep, vi, mail, news, etc. Benchmarks with significant I/O components measure your bus and disks, not your processor. And since you can put high-performance disks on most microprocessors these days, it is not surprising that your figures came out so high. 2. My experience with cpu-bound tasks (with little or no I/O and running essentially core-resident) on the 8MHz HP Series 200 and the 10MHz SMI 2-170 is that the VAX-11/780 is anywhere from 2 to 10 times faster, and most tests fall between 3 and 5 times faster given comparable code quality. 3. Just as you have been able to find a benchmark which runs faster on the 68K, I have a benchmark which ran 100 times faster on the 780 and did not use floating-point - these benchmarks are meaningless because they don't measure the machinery, they are measuring compiler and OS quality. It is very difficult to measure the real beast in these machines. 4. Your comment about the 200ns SBI is ludicrous - the 780 has a large cache and the SBI handles 64 bit packets, so there is no way that the SBI is kept busy - that is by design to allow enough bandwidth for other devices to do their stuff. One of the faults of the 68K family is the tendency to use up nearly all available bus bandwidth for instruction execution, leaving very little for I/O and coprocessors. 5. I've spent 8 years working with UNIX systems. I have yet to see a machine run 4.2 better than the 780 does (soon to change with the advent of the VAX 8600). If you do want to get into UNIX vs. VMS operating system comparisons, VMS does have significantly better compilers and quicker I/O so a lot of benchmarks run faster on it. While on this subject, no one has yet to run benchmarks on the 68020 with a compiler which uses the extended instruction set, so this should add a few percent to 68020 performance. 6. I would suggest that you read the article on the 68020 in IEEE Micro. If you had, you would not have so ridiculously over-simplified the performance implications of clock, bus, and cache. No, doubling the clock does not double performance. Sorry, you don't hit your instruction cache 100% of the time, so you'll have to wait around a bit more. Too bad, your 32-bit bus saturates just as quickly as on the 68010 (because of more 32-bit operands and the doubled clock speed fetching them). And multi-processors? With 70-90% of bus bandwidth gone, you had better have some really bright ideas on how to get out of this one, Ollie. Yes, it is going to take interleave, data cache, a blazing MMU, and all of the things we have come to expect from mainframes - but this all comes at a bigger pricetag. 7. I've based my figures on 5 years of experience with VAX and 68K systems (most of it not at Digital) - I'm reporting on what I've seen and what I think you can expect from the 68020 - at best you can expect 780 performance given comparable compilers on CPU intensive benchmarks. And that ain't too bad, if you ask me. all in the opinion of... Joe Falcone Eastern Research Laboratory decwrl! Digital Equipment Corporation decvax!deccra!jrf Hudson, Massachusetts tardis!