I find fusion very exciting also. I just wish it wasn’t so hard to figure out whether it’s happening or not. ;-)

For example, I have a program that would seem to be an ideal candidate for fusion. I have lots of arrays that get added to other arrays, multiplied by constants, mapped over by transformers, etc.

However, this is a kind of EDSL where the arrays are stored in an environment (a StateT basically acting as a Reader). They get pulled out, manipulated, and put back in to dynamically scope over the called code.

E.g.

– ignoring the possibility of Nothing from Map.lookup
a = local (Map.insert “sig” . Vector.map (*2) . Map.lookup “sig”) b
b = local (Map.insert “sig” . Vector.map (/2) . Map.lookup “sig”) c
c = …

I’m pretty sure in this case the two maps won’t fuse since GHC would have to figure out that from the point of view of ‘c’, the intermediate vector created by ‘a’ is not needed.

I have thought of storing the environment not as (Map String Vector) but as (Map String ([Vector -> Vector], Vector]). Then when someone actually wants the value of a vector, they pull it out and do a ‘foldr (.) id funcs vec’. That would avoid intermediate vectors at the cost of duplicated computation if the intermediate vector is used after all.

But I’m not sure that would fuse either, since I don’t know if rules will kick in when the functions are in a list like that.

Ideas? Advice? I’m curious about the limitations of fusion and how one can structure a program to expose more things to it.

Of course this sort of defeats the purpose of “write naturally and the compiler will make it fast”, but jumping through a few composition hoops would still be easier than manual fusion. Or would it? What if I store [Either (Int -> Int) (Vector -> Vector)], then manually fuse adjacent Lefts?

Even if the code perfectly represents the steps the CPU would take you still has to consider the effect of cache misses and other hard to predict realities of the execution context.

So just let it go. Assume the code will be optimized as good as theoretically possible by the compiler and runtime and focus on making it as readable and maintainable as possible instead.

I want to personally encourage you to keep writing these posts about GHC. My day job lands my thoughts square in the land of C, but whenever one of these posts makes it on to the news aggregator sites I find myself breaking out GHCi yet again.

Hopefully one of these days I won’t have to put it away.

In general, if you’re using vector you don’t need to care about fusion — since it’s all designed that way (same for the existing fusion mechanisms for lists).

Now, if you’re really interested (say you’re doing some high performance numerics), then you’d use a tool like ghc-core to watch for fusion sites. GHC will let you know what it finds.