On Sun, Oct 9, 2011 at 10:54 AM, Roman Cheplyaka wrote:

* Jan-Willem Maessen [2011-10-08 12:32:18-0400]

...

It seems to be a common misconception that eta-abstracting your functions in this way will speed up or otherwise improve your code.

Simon PJ has already provided a good explanation of why GHC eta expands.  Let me take another tack and describe why the code you wrote without eta expansion probably doesn't provide you with any actual benefit.  Roughly speaking, you're creating a chain of closures whose contents exactly describe the contents of your list (ie you've created something that's isomorphic to your original list structure), and so you should expect no benefit at all.

Thanks for the analysis.

I used myFoldl as a minimal example to ask the question.

Here's an example of real code where this does make a difference: https://github.com/feuerbach/regex-applicative/tree/03ca9c852f06bf9a9d515056...

Ah, now things get more complicated! :-) I suspect here you're actually entering the regexp closures, and compiling it down is actually saving you a teensy bit of interpretive overhead.

... What's even more interesting (and puzzling!), if remove -fno-do-lambda-eta-expansion for Text/Regex/Applicative/Types.hs, the benchmark takes 2.82 seconds.

That *Is* odd. The only obvious code generated here would be the newtype instances, for which this should surely be irrelevant? Can someone at GHC HQ explain this one? -Jan

The only difference in generated code is in the showsPrec function for a newtype-wrapped Int (ThreadId). The code actually never (explicitly) uses Show instance -- it's only needed as a dependency for Num instance. Could it be some cache effect? I'll see if I can reduce that code and then will file a bug. * Simon Peyton-Jones [2011-10-12 10:56:04+0000]

Roman, Jan-Willem

I'm maxed out at the moment, and will be so for at least a week.

If you think there is something mysterious and J-W agrees, could you create a ticket, with the smallest example you can, and instructions to reproduce? That'd be brilliant.

Of course, Jan-Willem, if you have a moment to diagnose a bit more about WHY it's going slower that would be even better!

Thanks

Simon

| -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Jan-Willem Maessen | Sent: 10 October 2011 02:51 | To: Roman Cheplyaka | Cc: glasgow-haskell-users@haskell.org | Subject: Re: Unwanted eta-expansion | | On Sun, Oct 9, 2011 at 10:54 AM, Roman Cheplyaka wrote: | > * Jan-Willem Maessen [2011-10-08 12:32:18-0400] | >> It seems to be a common misconception that eta-abstracting your | >> functions in this way will speed up or otherwise improve your code. | >> | >> Simon PJ has already provided a good explanation of why GHC eta | >> expands.  Let me take another tack and describe why the code you wrote | >> without eta expansion probably doesn't provide you with any actual | >> benefit.  Roughly speaking, you're creating a chain of closures whose | >> contents exactly describe the contents of your list (ie you've created | >> something that's isomorphic to your original list structure), and so | >> you should expect no benefit at all. | > | > Thanks for the analysis. | > | > I used myFoldl as a minimal example to ask the question. | > | > Here's an example of real code where this does make a difference: | > https://github.com/feuerbach/regex- | applicative/tree/03ca9c852f06bf9a9d51505640b8b72f07291c7d | | Ah, now things get more complicated! :-) I suspect here you're | actually entering the regexp closures, and compiling it down is | actually saving you a teensy bit of interpretive overhead. | | > ... | > What's even more interesting (and puzzling!), if remove | > -fno-do-lambda-eta-expansion for Text/Regex/Applicative/Types.hs, | > the benchmark takes 2.82 seconds. | | That *Is* odd. The only obvious code generated here would be the | newtype instances, for which this should surely be irrelevant? Can | someone at GHC HQ explain this one? | | -Jan | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-- Roman I. Cheplyaka :: http://ro-che.info/