possible tuple elimination optimization?

George Colpitts george.colpitts at gmail.com
Sat Mar 26 17:50:32 UTC 2016


The following higher order function, sumh, seems to be 3 to 14 times slower
than the equivalent recursive function, sumr:

sumh :: Double -> Double
sumh n =
    snd $ until ((>= n) . fst) as' (1, 0)
    where
      as' (i,s) =
          (i + 2, s + (-1) / i + 1 / (i + 1))

sumr :: Double -> Double
sumr n =
    as' 1 0
    where
      as' i  s
          | i >= n    = s
          | otherwise = as' (i + 2) (s + (-1) / i + 1 / (i + 1))

This is true in 7.10.3 as well as 8.0.1 so this is not a regression. From
the size usage my guess is that this is due to the allocation of tuples in
sumh. Maybe there is a straightforward way to optimize sumh but I couldn't
find it. Adding a Strict pragma didn't help nor did use
of -funbox-strict-fields -flate-dmd-anal. Have I missed something or should
I file a bug?

Timings from 8.0.1 rc2:

ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160204
bash-3.2$ ghc -O2 -dynamic sum.hs
ghc -O2 -dynamic sum.hs
[1 of 1] Compiling Main             ( sum.hs, sum.o )
Linking sum ...
bash-3.2$ ghci
Prelude> :load sum
Ok, modules loaded: Main.
(0.05 secs,)
Prelude Main> *sumh* (10^6)
-0.6931466805602525
it :: Double
(*0.14 secs, 40,708,016 bytes*)
Prelude Main> sumr (10^6)
-0.6931466805602525
it :: Double
(*0.01 secs, 92,000 bytes)*

Thanks
George
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160326/7b1490a7/attachment.html>


More information about the ghc-devs mailing list