This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC Benchmarks (coybench), AMD64 and i686, 14 August 2004
- From: Wolfgang Bangerth <bangerth at ices dot utexas dot edu>
- To: Scott Robert Ladd <coyote at coyotegulch dot com>
- Cc: Joe Buck <Joe dot Buck at synopsys dot com>, gcc at gcc dot gnu dot org
- Date: Wed, 18 Aug 2004 08:18:33 -0500
- Subject: Re: GCC Benchmarks (coybench), AMD64 and i686, 14 August 2004
> A good point. I wrote my first benchmark article for Micro Cornucopia back
> in 1988, and ran into exactly the problem above. When I wrote a review of
> Fortran compilers for Computer Language in about '90, we had trouble with
> compilers built for specific benchmarks, and vendors who complained loudly
> if we did not use the specific benchmarks they were best at optimizing. And
> today we have chicanery involving drivers for various video cards -- ugh.
>
> To combat this, I use non-standard benchmarks, often reducing larger "real
> world" programs to find something easily understandable yet complex enough
> to stress compilers' code generation.
Organizations like SPEC are clearly aware of these shortcomings of testsuites.
The newer generation programs in their suites are mostly complete real world
programs, rather than manufactured small ones. The criteria for inclusion
into SPEC also propose that programs have flat profiles without hotspots, so
that microoptimizations of a few patterns don't give you so much anymore.
> Consider that my "mole" benchmark is *not* a well-known benchmark program,
> and I published it *after* the release of the Intel compiler I'm using. I
> don't see how they could have anticipated my benchmark, unless another,
> better-known benchmark includes a similar function.
Mole is a pretty well-known piece of code. It may be included in other
testsuites as well.
W.
-------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth@ices.utexas.edu
www: http://www.ices.utexas.edu/~bangerth/