This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC Benchmarks (coybench), AMD64 and i686, 14 August 2004


On Tue, Aug 17, 2004 at 04:33:30PM -0400, Scott Robert Ladd wrote:
> Given that Intel is smart-enough to generate both correct and fast code 
> from the source, GCC should be able to do the same. I'm thankful that we 
> have a very smart group of people who are working hard on such matters.

There's an issue here.  I hesitate to call it "ethics", but it is
borderline.

The issue is whether the compiler should specifically detect certain
transformation opportunities in benchmarks that are unlikely to exist in
real code, to get an artificially high score on that benchmark that does
not reflect what the user can expect on code that the compiler developers
have not seen before.

A classic example was the Whetstone benchmark, where many compiler
developers started specifically recognizing a particular expression
involving transcendental functions and applying a mathematical identity to
speed it up.  This particular transformation is useless for anything
except speeding up Whetstone, but it slows down the compiler a bit for all
programs.

In this case, a transformation could be added as part of -ffast-math that
would specifically recognize

inline static double dv(double x)
{
    return 2.0 * sin(((x < PI2) ? x : PI2)) * cos(((x < PI2) ? x :
PI2));
}

and transform it into

inline static double dv(double x)
{
    return x >= PI2 ? 0.0 : sin(2.0 * x);
}

just to get a high score on mole.  But that strikes me as close to
immoral; any tranformation should fall out of some generally useful
transformation sequence.  For example, if (x < PI2 ? x : PI2) is
recognized as a common subexpression, we have

inline static double dv(double x)
{
   double arg = x < PI2 ? x : PI2;
   return 2.0 * sin(arg) * cos(arg);
}

This might then be turned into

inline static double dv(double x)
{
   if (x < PI2)
       return 2.0 * sin(x) * cos(x);
   else
       return 0.0;
}

and if ICC does it this way, I would not consider this "cheating" at all.
That could be justified.  The trig identity that 2*sin(x)*cos(x) is
sin(2*x) is more iffy; we'd waste time trying to apply such
transformations to every tree, and it's pretty much exactly what caused
such controversy when everyone did it to Whetstone.





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]