#5113: Huge performance regression of 7.0.2, 7.0.3 and HEAD over 7.0.1 and 6.12
(MonoLocalBinds)
--------------------------------------+-------------------------------------
Reporter: daniel.is.fischer | Owner:
Type: bug | Status: closed
Priority: normal | Milestone:
Component: Compiler | Version: 7.0.3
Resolution: fixed | Keywords: performance,
MonoLocalBinds
Os: Linux | Architecture: x86
Failure: Runtime performance bug | Difficulty: Unknown
Testcase: perf/should_run/T5113 | Blockedby:
Blocking: | Related:
--------------------------------------+-------------------------------------
Changes (by simonpj):
* difficulty: => Unknown
Comment:
This patch is the crucial one that fixes the original problem
{{{
commit b5c18c91da911a7729563207c7b95f7e452cca7e
Author: Simon Peyton Jones <[email protected]>
Date: Fri Feb 8 17:29:40 2013 +0000
Fix an old and egregious specialisation bug (Trac #5113)
The specialiser needs to know if a dictionay has some structure,
so that it can decide whether to specialise a function. Eg
(A) let d = $dfblah d1
in ....(f d)....
(B) \d. ....(f d)....
In (A) it's probably worth specialising f; in (B) it isn't.
Previously we were relying on d's unfolding, but the specialiser
does cloning as it goes, which discards the unfolding. So we
were simply discarding all specialisations for functions with
local dictionary bindings! This bug seems to have been there
for a long time.
This is what originally caused Trac #5113. Then we went through a
phase
where local bindings were not generalised, and that meant there was
no locally overloaded f to specialise; so the performance problem
appeared
to be fixed. But now we are generalising local bindings again, so it
re-appeared.
This patch fixes the original problem.
compiler/specialise/Specialise.lhs | 390
++++++++++++++++++++----------------
1 files changed, 214 insertions(+), 176 deletions(-)
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5113#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
ghc-tickets mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-tickets
