#4474: 3 ways to write a function (unexpected performance difference and
regression)
---------------------------------+------------------------------------------
Reporter: claus | Owner: igloo
Type: bug | Status: new
Priority: normal | Milestone: 7.2.1
Component: Compiler | Version: 7.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Windows | Blocking:
Architecture: Unknown/Multiple | Failure: Runtime performance bug
---------------------------------+------------------------------------------
Changes (by simonpj):
* owner: => igloo
Comment:
Right this is fixed by
{{{
Tue Dec 21 16:58:00 GMT 2010 [email protected]
* Add a simple arity analyser
I've wanted to do this for ages, but never gotten around to
it. The main notes are in Note [Arity analysis] in SimplUtils.
The motivating example for arity analysis is this:
f = \x. let g = f (x+1)
in \y. ...g...
What arity does f have? Really it should have arity 2, but a naive
look at the RHS won't see that. You need a fixpoint analysis which
says it has arity "infinity" the first time round.
This makes things more robust to the way in which you write code. For
example, see Trac #4474 which is fixed by this change.
Not a huge difference, but worth while:
Program Size Allocs Runtime Elapsed
--------------------------------------------------------------------------------
Min -0.4% -2.2% -10.0% -10.0%
Max +2.7% +0.3% +7.1% +6.9%
Geometric Mean -0.3% -0.2% -2.1% -2.2%
I don't really believe the runtime numbers, because the machine was
busy, but the bottom line is that not much changes, and what does
change reliably (allocation and size) is in the right direction.
M ./compiler/coreSyn/CoreArity.lhs -51 +35
M ./compiler/coreSyn/CoreUtils.lhs -5 +6
M ./compiler/simplCore/SimplUtils.lhs -1 +94
}}}
Ian, since Clause has given us a nice timeable program, could you turn it
into a performance test? (NB the "n" is the naive way, which should be
slow.)
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4474#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs