#3737: inlining happens on foldl1 and does not happen on direct application of
combinator
-----------------------+----------------------------------------------------
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 6.10.4 | Keywords:
Os: Linux | Testcase:
Architecture: x86 | Failure: Runtime performance bug
-----------------------+----------------------------------------------------
This is certainly related to #3736.
The code can be found at:
http://code.haskell.org/storablevector/speedtest/SpeedTestChorus.hs
Look into functions mainChunky1MixFold and mainChunky1MixFlat.
The first one does
{{{
foldl1 mixVec $ map (uncurry tone0) $ [(f0,p0), (f1,p1), (f2,p2)]
}}}
and generator0Freq gets inlined and is fast. (1.4 seconds)
The second one does
{{{
tone0 f0 p0 `mixVec` tone0 f1 p1 `mixVec` tone0 f2 p2
}}}
and generator0Freq is not inlined and this is slower (2.0 seconds).
(Inlining or specialising mixVec doesn't change the numbers.
I tried that because I first thought, mixVec would be the problem.)
But we cannot derive from it, that using 'foldl1' is better in general.
Since if you compare mainMonolithic1GeneratorFold with
mainMonolithic1Generator,
you find that the fold version is slower (2.8 seconds vs. 2.0 seconds).
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3737>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
