Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!swrinde!mips!sgi!shinobu!odin!sgi.com!streich
From: streich@sgi.com (Mark Streich)
Newsgroups: comp.arch
Subject: Re: Compilers & SPECmarks...
Keywords: Compilers, SPEC
Message-ID: <1991Apr11.143529.17969@odin.corp.sgi.com>
Date: 11 Apr 91 14:35:29 GMT
Sender: news@odin.corp.sgi.com (Net News)
Reply-To: streich@sgi.com (Mark Streich)
Organization: sgi
Lines: 34

|> In article <1991Apr9.052607.12055@news.iastate.edu>, john@iastate.edu (Hascall John Paul) writes:
|> 
|>    Is it time to axe "matrix300" from the SPECsuite?  This makes the
|> second instance (others?) of SPECnum which can only be explained by
|> a compiler significantly reducing the problem.

Perhaps it is time to split the SPEC numbers into two pieces:

  1.  No change from what we get now, letting compilers do whatever they 
      can to the code.
  2.  A number based on how many integer and floating point operations 
      the program *actually* performs when being run.  Instead of getting
      "credit" for the number of operations to be executed as defined by
      the source code, "credit" is given for the runtime frequency of ops
      in the executable.

Example:  A source program calculating PI uses 1 million floating point
      operations to do the job.  The compiler, using pattern matching, 
      detects this case, and simply stuffs the value of PI into a variable
      and avoids doing all of the calculations.  

      (1) would give credit for all 1 millions flops (and why not? it solved
      the problem), but (2) would give credit only for the operations
      required to store the value into the variable.

We can't go solely to (2) because there would be less incentive to improve
the compilers, but it would give us the opportunity to compare architectures
on a more equal footing.  Would people prefer a system that performs 1M flops
per second or 1 flop per second if both solve the same problem?

Mark Streich
streich@sgi.com

#include <std.disclaimer>