Re: Fusion vs. inlining (Was: [Haskell-cafe] Fusion of lists and chunky sequences)

2008-01-09 Thread Henning Thielemann

On Tue, 8 Jan 2008, Roman Leshchinskiy wrote:

> Henning Thielemann wrote:
> >
> > Anyway, I tried to wrap Prelude lists in a newtype and thus got GHC (still
> > 6.4.1) to invoke my rules instead of the Prelude rules. But I encountered
> > the following problem: I define something like
> >
> >   nonFusable x y = fusable (aux x y)
> >
> >  where fusion rules are defined for 'fusable', but not for 'nonFusable'. I
> > hoped that 'nonFusable' will be inlined and then 'fusable' is fused with
> > other expressions. This does not happen. If I state the function
> > definition also as rule, then GHC fuses eagerly.
>
> I suspect that fusable and/or aux are inlined into nonFusable when the
> latter is compiled. That's too early - you want nonFusable (with the
> simple definition above) to be inlined into the client code first. Adding
>
>{-# INLINE nonFusable #-}
>
> should take care of this.

I forget to mention, that I already declared
  {-# INLINE nonFusable #-}

As you guessed, it seems that 'fusable' was inlined and thus was no longer
available for fusion. So I set INLINE for nonFusable and NOINLINE for
fusable. Now I see the foldr/build counter decreases in the simplifier
statistics, where the counter for my custom rules increases.


> >  Analogously I observed that usage of ($) and (.) blocks fusion, and when
> > I add the rules
> >
> >   "unfold-dollar" forall f x.
> >  f $ x = f x ;
> >
> >   "unfold-dot" forall f g.
> >  f . g  =  \x -> f (g x) ;
> >
> >  then fusion takes place as expected.
>
> That shouldn't be necessary, these two ought to be inlined. Do you have
> a concrete example where this happens?

 When I constructed a small example I encountered the behaviour you
mentioned. However there are still several cases where I expected that
fusion took place but it didn't. Maybe I can track them down to very
simple cases. Since the functions on the chunky structure can be faster
than the list functions by a factor of 30, I'm very keen on getting the
list functions eliminated completely.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: Fusion vs. inlining (Was: [Haskell-cafe] Fusion of lists and chunky sequences)

2008-01-07 Thread Roman Leshchinskiy

Henning Thielemann wrote:


Anyway, I tried to wrap Prelude lists in a newtype and thus got GHC (still
6.4.1) to invoke my rules instead of the Prelude rules. But I encountered
the following problem: I define something like

  nonFusable x y = fusable (aux x y)

 where fusion rules are defined for 'fusable', but not for 'nonFusable'. I
hoped that 'nonFusable' will be inlined and then 'fusable' is fused with
other expressions. This does not happen. If I state the function
definition also as rule, then GHC fuses eagerly.


I suspect that fusable and/or aux are inlined into nonFusable when the 
latter is compiled. That's too early - you want nonFusable (with the 
simple definition above) to be inlined into the client code first. Adding


  {-# INLINE nonFusable #-}

should take care of this.


 Analogously I observed that usage of ($) and (.) blocks fusion, and when
I add the rules

  "unfold-dollar" forall f x.
 f $ x = f x ;

  "unfold-dot" forall f g.
 f . g  =  \x -> f (g x) ;

 then fusion takes place as expected.


That shouldn't be necessary, these two ought to be inlined. Do you have 
a concrete example where this happens?


Roman

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe