Loop optimisation with identical counters

[christian Hoener zu Siederdissen]

Yes indeed, this is what some fusion code could look like. I deal with stuff like this:

mk i j = enumFromN (i+1) (j-i-2) -- gen indices, sometimes index pairs

f i j k = T!(i,k) + T!(k+1,j) -- table lookup using some 2d tables

g i j k = fun i k + fun (k+1) j -- some funny calculation

z i j = minimum $ zipWith (+) (map (f i j) $ mk i j) (map (g i j) $ mk i j)

y i j = minimum (map (g i j) $ mk i j)

So i would like to split my calculations into f and g as sometimes (in backtracking results) only g is needed. Furthermore, there are like 12 different f g z y mk each.

Being able to seperate the worker into f g means cleaner code and that it is easier to change stuff. Note that mk in f is always called with the same borders, leading to things like my original problem. But Roman has already pointed out how often this duplication of counters can occur.

Gruss,
Christian

PS: above is a bit pseudocode-like but captures the essentials and my thumbs are numb now... ;-)

----- Original message -----
> On 06/11/2010, at 02:27, Sebastian Fischer wrote:
> 
> > Interesting. This approach requires `f` to be inlined into its call
> > site in order to eliminate the redundant argument. This is different
> > from the proposal to provide a specialized version of `f` (where the
> > arguments are combined) which could be reused at different call sites.
> 
> Which proposal do you mean? I'm not sure something like that is feasible
> without knowing the call sites. You have to know which arguments to
> combine.
> 
> > How many call sites with identical arguments are there in the
> > generated code that triggered this discussion and in the stream fusion
> > code that would benefit from this optimization?
> 
> In stream fusion code, there is normally exactly one call site. I
> suspect that the Christian's example has also been derived from stream
> fusion code.
> 
> Roman
> 
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users