Polyhedron speed comparison (on AMD64)

[Uros Bizjak]

On 11/30/06, Paul Thomas <paulthomas2@wanadoo.fr> wrote:

> > First, you remember our big regression for ae on AMD64? This has now
> > been partially fixed by Uros (using x87 for fmod):

> > Thus we are not yet back at our original speed, maybe one should find
> > the reason for the extra 2s step at Nov 13/14.
> >
> Nothing stands out in fortran or libgfortran, does it?

I'd propose a bisection search for the offending change. However, it
takes a couple of rebuilds to find it. I've done it a couple of times
by hand in the past, but a script could come really handy there.

Basically, you start from the current HEAD and create a svn diff -r
xxx, where xxx represents starting revision. Apply this diff as a
reversed patch and rebuild gfortran (use --enable-languages=c,fortran
--disable-bootstrap here). Benchmark it.

Following this, you create a diff between current revision and some
later revision. You can check ChangeLog diffs, if there was some
activity in areas you are interested in (script can't do this...) and
repeat above... If you know approximate time frame, it could be better
to do a linear search instead of bisection, but it takes around 3-5
rebuilds to find the offender.

Looking at [1], there is at least one more point of interest,
performance drop in protein somewhere in the same time frame as
performance drop in ac.

BTW: A lot of loop optimizer patches went into the mainline during
this time frame. Perhaps one of them could introduced this performance
regression?

[1] http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt-2-0.html

Uros.