On Mar 4, 2010, at 9:05 PM, Roman Leshchinskiy wrote:
> On 05/03/2010, at 04:34, stefan kersten wrote:
>
>> i've been hunting down some performance problems in DSP code using vector and
>> the single most important transformation seems to be throwing in INLINE
>> pragmas
>> for any function that uses vector combinators and is to be called from
>> higher-level code. failing to do so seems to prevent vector operations from
>> being fused and results in big performance hits (the good news is that the
>> optimized code is quite competitive)....
>
>> the downside after adding the INLINE pragmas is that now some of my modules
>> take
>> _really_ long to compile (up to a couple of minutes); any ideas where i can
>> start looking to bring the compilation times down again?
>
> Alas, stream fusion (and fusion in general, I guess) requires what I would
> call whole loop compilation - you need to inline everything into loops. That
> tends to be slow. I don't know what your code looks like but you could try to
> control inlining a bit more. For instance, if you have something like this:
>
> foo ... = ... map f xs ...
> where
> f x = ...
>
I can confirm that this is a general problem with libraries based on fusion /
deforestation (having done the independent implementation of fusion in pH back
in the day). No INLINE pragma? No fusion for you!
That said, as Roman points out it'd be nice if when GHC discovers something is
inlinable, it would inline the original definition (or perhaps the inlined,
simplified, no-rules-firing version of same). The problem is that this
duplicates a lot of the work of the optimizer a lot of the time.
> you could tell GHC not to inline f until fairly late in the game by adding
>
> {-# INLINE [0] f #-}
>
> to the where clause. This helps sometimes.
Hands up if you can remember what things are legal in the braces, and what they
mean. :-) I suspect I'm not the only one for whom remembering this stuff is
fairly hard, in part because it doesn't come up too often.
-Jan-Willem Maessen_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
