[GHC] #10788: performance regression involving minimum
GHC
ghc-devs at haskell.org
Mon Sep 7 22:02:56 UTC 2015
#10788: performance regression involving minimum
-------------------------------------+-------------------------------------
Reporter: rwbarton | Owner: ekmett
Type: bug | Status: closed
Priority: normal | Milestone:
Component: Core Libraries | Version: 7.10.1
Resolution: fixed | Keywords:
Operating System: Unknown/Multiple | Architecture:
Type of failure: Runtime | Unknown/Multiple
performance bug | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Revisions:
-------------------------------------+-------------------------------------
Comment (by simonpj):
> Update: I looked into this, and it seems that even if -ddump-simpl
looks like this, with a space-leaky way of accumulating the argument, that
in the CorePrep stage the evaluation of cmax is pulled before the call to
go and alls is well. I did not know that there are still such things going
on in that stage.
Suppose we have a function call `f (g x)` and `f` is strict. Then GHC
keeps it looking like that so that rewrite rules apply easily. In
`CorePrep` GHC just makes the order of evaluation explicit, by moving to
{{{
case (g x) of y -> f y
}}}
There is no new analysis; the call always was call-by-value; but after
`CorePrep` that fact is 100% explicit.
I believe that the conclusion here is that GHC is behaving perfectly
predictably; but library authors need to take a little care with pragmas
and rules if they want to get predictable fusion. That's what your email
in comment:9 is about, if I read it right. That is, you are not seeking
any change to GHC. Correct?
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10788#comment:15>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list