2008/7/18 Mitar <[EMAIL PROTECTED]>: > On Sat, Jul 12, 2008 at 3:33 AM, Max Bolingbroke > <[EMAIL PROTECTED]> wrote: >> If findColor had been a function defined in terms of foldr rather than >> using explicit recursion, then theres a good chance GHC 6.9 would have >> fused it with the list to yield your optimized, loop unrolled, >> version: > > My first version was with msum. Is this also covered by this fusion?
Note that as I said the fusion only applies to 6.9 onwards. However, assuming that you were using msum at the list monad then since msum = concat is defined in terms of foldr there is a chance it could happen. The best guide to this kind of thing is not asking me but rather looking at the Core output by GHC for your particular program. > (And it is interesting that my own recursion version is faster than > the version with msum. Why?) I don't know why you find this suprising :-). Your own version is specialized exactly for the situation you wish to use it for. msum is a generic combinator, which naturally makes it less amenable to optimization because there is less information available about it's usage pattern. Note that GHC will of course try to do its best to de-specialize the msum function for any particular scenario it's used in, through inlining etc, but there are no guarantees. > It is a little more tricky. I choose in an IO monad which scene it > will render (selected by a program argument). So at compile time it > does not yet know which one it will use. But there is a finite number > of possibilities (in my case two) - why not inline both versions and > at run time choose one? If there was only one static occurance of each identifier in your module then it would do that. This is because there is no code size implications for inlining a function into it's unitary use site. Inlining is not a cure-all for performance though: if you inline too much then you increase code size and hence increase the amount of main memory you're reading and reduce instruction cache hits, not to mention fill up your disk with multi-MB binaries. Max _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
