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!