where's the speed? (performance regressions)

[Joe Buck]

> Since (at least) snapshot 971225 of egcs I get a speed *decrease* on
> i586-pc-linux-gnu when I select -funroll-all-loops (say, 4%-5% on gzip).
> 
> Formerly, I got an 4-5% increase when using -funroll-all-loops on x86.
> 
> Has anybody else measured such a difference?

Yes, Dan Bernstein (famous for the "Snuffle" cryptography lawsuit) says he
sees a significant slowdown for egcs on the Pentium vs 2.7.2 for his
fast FFT code, probably because of a misoptimized inner loop:

> ... and with -O6 -mpentium it makes my code
> a solid 25% slower than gcc 2.7.2 did with -O6 -m486. I'm impressed.

I hadn't mentioned this yet because I hadn't had a chance to verify it,
but since I won't have time for a while I'm passing this on.

The code he's describing can be found at

ftp://koobera.math.uic.edu/pub/software/djbfft-0.60.tar.gz

There is a document on it at

http://pobox.com/~djb/djbfft.html

which says in part:

<h2>What is it?</h2>
djbfft is the fastest available code for small power-of-2 complex DFTs
on a Pentium. It's also reasonably fast on other machines.
<p>
djbfft does a recursive in-place split-radix decimation-in-frequency
FFT, with precomputed roots of unity, using my ``3 to -1'' improvement
to chop the number of root loads in half. One split-radix pass fits
nicely into the Pentium's 8 floating-point registers. For machines with
more registers it would be better to do two passes at once.
<p>
djbfft does not yet attempt to limit cache misses. For large transforms
the number of simultaneous passes should be matched to the details of
the memory hierarchy, as per Gentleman-Sande.