Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ll-xn!adelie!axiom!linus!philabs!pwa-b!mmintl!franka
From: franka@mmintl.UUCP (Frank Adams)
Newsgroups: net.arch
Subject: Re: Benchmarks in August IEEE Micro
Message-ID: <1864@mmintl.UUCP>
Date: Wed, 8-Oct-86 14:34:49 EDT
Article-I.D.: mmintl.1864
Posted: Wed Oct  8 14:34:49 1986
Date-Received: Fri, 17-Oct-86 03:27:55 EDT
References: <322@oblio.UUCP> <3600003@hplabsb.UUCP> <21344@rochester.ARPA>
Reply-To: franka@mmintl.UUCP (Frank Adams)
Organization: Multimate International, E. Hartford, CT
Lines: 18

In article <21344@rochester.ARPA> crowl@rochtest.UUCP (Lawrence Crowl) writes:
>By the same token, including the [compiler] is often an invalid comparison
>because the compiler can have a significant effect on the resulting
>performance.  Suppose I take a student built, unoptimizing compiler for
>machine A and a highly tuned optimizing compiler for machine B.  Now, if
>the two machines are anywhere close in performance, machine B will win.
>Here again, the bottom line is that we must trust the benchmarks, correlate
>them with other benchmarks, or do them ourselves.

The issue here is who is using the benchmarks, and for what?  If, as for most
of us, writing one's own compiler is not an option, then all that matters is
how our program will perform using the compilers available for it.  It
doesn't much matter if machine A is really faster than machine B, if the
only compilers available for machine A generate code which is so much worse
than that available on machine B that the programs actually run slower.

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Multimate International    52 Oakland Ave North    E. Hartford, CT 06108