On Nov 11, 2014 6:04 AM, "Simon Peyton Jones" <simo...@microsoft.com> wrote: > 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.
The inliner does indeed do amazing things, and list fusion does indeed do lovely things for user code. It's just not the most *reliable* optimization in the compiler. I don't think there's anything wrong with admitting that and trying to avoid relying on it too heavily in *library* code. Kim-Ee was right that expanding out mapM by hand bloated the source. I've since defined `sequence=mapM id` to resolve that problem, and doing so does not hurt the benchmarks—it relies only on inlining id (which is quite reliable) and beta-reducing (which is also quite reliable). > 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]. I've been trying to leave a trail of comments and notes as I go. I may need to go further.
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
