[GHC] #9781: Make list monad operations fuse

[Simon Peyton Jones]

The inliner is a finicky beast. In response to your insults, I will say that although GHC has beautiful ideas in it, a lot of the details of the optimization passes and how they fit together *are* a bit of a crapshoot, chosen by benchmarks rather than theory.

It’s true that, particularly for fusion, inlining can make a huge difference.  And GHC really does need help… it’s extremely hard for it to make the “right” choice all the time.

I strongly agree with Kim-Ee that we should play the game of “optimise by randomly mutating the program and pick the version that (today) happens to run faster”.  But I don’t think David is doing that.   There is, at least a Note: [List comprehensions and inlining].

What we should do is to

·         understand which the crucial inlining decisions are, and why

·         express that understanding in a Note, so that subsequent people looking at the code also understand

·         remove any un-necessary code cruft, which sometimes accumulates during a period of experimentation, leaving the minimum necessary to achieve the effect

I’m not quite certain that all these steps have been done here, and they can be tiresome to do.  But worth it!

Simon

From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of David Feuer
Sent: 11 November 2014 09:12
To: Kim-Ee Yeoh
Cc: Haskell Libraries; ghc-devs
Subject: Re: [GHC] #9781: Make list monad operations fuse


On Nov 11, 2014 3:56 AM, "Kim-Ee Yeoh" <ky3 at atamo.com<mailto:ky3 at atamo.com>> wrote:
>
> From the patch fragment at
>
> https://phabricator.haskell.org/D455?id=1311#inline-3123
>
> What's the justification for expanding out the definition of mapM from "sequence . map f" into do-notation and duplicated code?
>
> Observe how mapM now duplicates code from sequence.

One good option might be to redefine sequence in terms of mapM.

> The absence of benchmarks is bad enough. What's worse is that the given excuse boils down to "Pity the poor compiler! Let's take over its work instead. Like, just in case, you know."

The excuse is that it actually makes a big difference for nofib. Why? I would have to guess it relates to what inlines when. The inliner is a finicky beast. In response to your insults, I will say that although GHC has beautiful ideas in it, a lot of the details of the optimization passes and how they fit together *are* a bit of a crapshoot, chosen by benchmarks rather than theory. Theory sometimes comes up behind and explains why the benchmarks do what they do, but you can't expect every little change to be backed up by some deep theoretical reason.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141111/a05b3be2/attachment-0001.html>