Compiler optimizations questions for ghc 6.10...
Bertram Felgenhauer
bertram.felgenhauer at googlemail.com
Sat Feb 21 03:52:00 EST 2009
Krasimir Angelov wrote:
> Well I actually did, almost. I added this function:
>
> quotX :: Int -> Int -> Int
> a `quotX` b
> | b == 0 = error "divZeroError"
> | b == (-1) && a == minBound = error "overflowError"
> | otherwise = a `quotInt` b
>
> It does the right thing. However to be sure that this doesn't
> interfere with some other GHC magic the real quot function have to be
> changed and tested. I haven't build GHC from source for 2-3 years now
> and I don't have the time to do it just to test whether this works.
It works, and it has the desired effect. It's not always a win though;
the nofib prime sieve benchmark suffers.
For a patch, see
http://int-e.home.tlink.de/haskell/ghc-libraries-base-tune-division.patch
Nofib results extract:
------------------------------------------------------------------------
Program Size Allocs Runtime Elapsed
------------------------------------------------------------------------
fish -0.7% -5.3% 0.05 0.04
primes -0.0% +28.5% +25.6% +25.5%
wheel-sieve2 -0.0% -0.3% -17.9% -18.6%
------------------------------------------------------------------------
Min -0.9% -5.3% -17.9% -18.6%
Max +0.1% +28.5% +25.6% +25.5%
Geometric Mean -0.2% +0.2% -0.0% +0.2%
'primes' is an outlier - the other slowdowns are below 3%
What happens in 'primes' is that 'mod' no longer gets inlined;
apparently it now looks bigger to the compiler than before.
Using -funfolding-use-threshold=10 brings the benchmark back to its
original speed, despite the extra comparison before doing the
division.
In 'wheel-sieve2', the first different optimization choice I see is
again a 'mod' that is no longer inlined; this leads to a change in other
inlining choices that result in a speedup for reasons that I have not
investigated.
Bertram
More information about the Glasgow-haskell-users
mailing list