Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!elbereth!rutgers!sri-spam!sri-unix!hplabs!hp-sdd!ncr-sd!ncrcae!sauron!campbell
From: campbell@sauron.UUCP (Mark Campbell)
Newsgroups: net.arch
Subject: Re: Benchmarks in August IEEE Micro
Message-ID: <731@sauron.UUCP>
Date: Thu, 2-Oct-86 10:58:28 EDT
Article-I.D.: sauron.731
Posted: Thu Oct  2 10:58:28 1986
Date-Received: Sat, 4-Oct-86 10:20:25 EDT
References: <322@oblio.UUCP> <3600003@hplabsb.UUCP>
Reply-To: campbell@sauron.UUCP (Mark Campbell)
Organization: NCR Corp., Advanced System Development, Columbia, SC
Lines: 24

In article <3600003@hplabsb.UUCP> wiemann@hplabsb.UUCP (Alan Wiemann) writes:
>Benchmark comparisons give valid results only if the same program is presented
>to each machine.  The compiler is considered part of the "machine" and its
>performance contributes to the overall performance of the machine.
> [...]

I don't believe that this is a valid point.  The article benchmarks
*processors*, not systems.  While the compiler is part of a system, it is
not part of a processor.  You are correct that the skill of the assembler
programmer is quite important -- however, using a compiler would only have
raised an issue concerning the skill of the compiler writer.

What I found ludicrous in the article was that they found that (to paraphrase)
'an internal cache was quite helpful'.  The way they set up the hardware it
should have been pretty damned obvious that an internal cache would be helpful.
The I80386 results were not made making use of 2 cycle external memory accesses.
With the delays induced for external memory accesses, those machines with
internal caches were clearly superior.  I guess that helps a lot if you are
going to build a 16/20MHz M68020/I80386 system with ~150ns DRAM and no external
cache (ala Compaq).  But it sure doesn't mean much to most of the Unix boxes
out there.
-- 

Mark Campbell    Phone: (803)-791-6697     E-Mail: !ncsu!ncrcae!sauron!campbell