Re: Re[2]: Compiler optimizations questions for ghc 6.10...
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 SizeAllocs 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: Compiler optimizations questions for ghc 6.10...
How mod is affected by the change in quot? Currently mod is defined as: a `mod` b | b == 0 = divZeroError | a == minBound b == (-1) = overflowError | otherwise = a `modInt` b and modInt is defined via remInt# which is primitive. Did you change the definition of mod as well? I agree that this change in the definition of quot is just a workaround. The best solution would be to do something clever in the compiler itself. For now if someone wants fast division then he/she should use quotInt. On Sat, Feb 21, 2009 at 9:52 AM, Bertram Felgenhauer bertram.felgenha...@googlemail.com wrote: 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 SizeAllocs 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: Compiler optimizations questions for ghc 6.10...
Hello Krasimir, Friday, February 20, 2009, 11:00:30 AM, you wrote: and this is exactly what we get. I bet that if the original function was: well, you check this yourself! :) -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: Compiler optimizations questions for ghc 6.10...
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. Regards, Krasimir On Fri, Feb 20, 2009 at 9:22 AM, Bulat Ziganshin bulat.zigans...@gmail.com wrote: Hello Krasimir, Friday, February 20, 2009, 11:00:30 AM, you wrote: and this is exactly what we get. I bet that if the original function was: well, you check this yourself! :) -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
