Xref: utzoo gnu.gcc:56 comp.arch:7123
Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!umigw!ncar!boulder!sunybcs!oswego!nyser!cmx!amax.npac.syr.edu!anand
From: anand@amax.npac.syr.edu (Anand Rangachari)
Newsgroups: gnu.gcc,comp.arch
Subject: Re: Common Compilers for benchmarks (was: Re: benchmarking)
Keywords: gcc silicon compilers RTL MIPS
Message-ID: <814@cmx.npac.syr.edu>
Date: 8 Nov 88 13:05:35 GMT
References: <7352@wright.mips.COM> <26627@ucbvax.BERKELEY.EDU> <474@oracle.UUCP>
Sender: usenet@cmx.npac.syr.edu
Reply-To: anand@amax.npac.syr.edu (Anand Rangachari)
Organization: Northeast Parallel Architectures Center
Lines: 22

In article <474@oracle.UUCP> csimmons@oracle.UUCP (Charles Simmons) writes:
[...]
>Of course, even using GCC to run all benchmarks still leaves you
>open to differences in the skill of a compiler writer.  An untuned
>implementation of GCC might not contain as many peephole optimizations
>as would be desirable, or one of the instructions in the instruction
>set may not have been described.  On the other hand, if you give me
>a benchmark, it becomes relatively easy to tune GCC to run that particular
>benchmark quickly.

  I was just wondering if that was such a bad thing after all. After all, a
benchmark is supposed to be representative of the typical programs a user
may want to run. Thus in improving the speed of a benchmark, you may 
actually improve the speed of a sizeable number of programs.

  An excellent argument against this is of course is that we dont have such 
benchmarks available (So I have gathered from the discussions on this
group).

                                                R. Anand
Internet: anand@amax.npac.syr.edu
Bitnet:   ranand@sunrise