Recursive functions and constant parameter closures
(inlining/strictness analyzer question)
bulat.ziganshin at gmail.com
Fri May 30 09:32:11 EDT 2008
Friday, May 30, 2008, 5:30:25 PM, you wrote:
may be i don't understand something. isn't it better to do automatic
SAT and inline results for every recursive function marked as INLINE?
it's how i want to work - just mark with INLINE speed-critical funcs.
manual checking that they are recursive and doing appropriate
transformation is too hard for me :) and, btw, how about adding
warnings about functions marked as INLINE which was not actually
inlined due to some reasons - may be very helpful for optimizing
programs without going into studying Core output
> Others have explained this nicely. But there's a real tension
> here. The fast version comes from a combination of (a) the static
> argument transformation, so you get the first version above, and (b)
> bodily inlining the entire function, so that at *each call site* you
> get a locally-recursive function where 'f' is known. That's ok for
> small functions, but not so good for big ones. Furthermore, the
> code duplication is only worthwhile if the specialisation is truly
> useful. For example, would it be better to write append like this
> (++) xs ys = letrec app  = ys
> app (x:xs) = x : app xs
> in app xs
> and inline that at every call of (++)? Probably not.
> So that is why GHC does not automate this transformation. If you
> know that's what you want, write a local recursion, and use an INLINE pragma.
> If someone felt like summarising this thread on the Haskell
> performance-advice wiki that would be great.
> Meanwhile, I'll clarify in the user manual that recursive functions are not inlined.
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
Bulat mailto:Bulat.Ziganshin at gmail.com
More information about the Glasgow-haskell-users