#2289: Needless reboxing of values when returning from a tight loop
----------------------------------------+-----------------------------------
Reporter: dons | Owner:
Type: run-time performance bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.8.2
Severity: normal | Resolution:
Keywords: boxing, loops, performance | Difficulty: Unknown
Testcase: | Architecture: Unknown
Os: Unknown |
----------------------------------------+-----------------------------------
Changes (by simonpj):
* difficulty: => Unknown
Comment:
Nice example. I took a little look at it. Two things
First, yes GHC never does a heap-check at the start of an alternative of a
primop case; that is, one whose scrutinee is just a primop application.
In this example that's bad, because there is no allocation before the
conditional, and the hot path does no allocation at all.
The fix is to put the heap check at the start of the alternatives, if no
allocation precedes the case itself. This would require a significant
(but not drastic) change to the code generator. Happily, it'll be a much
easier change when John Dias's new back end comes on stream, we'll hold it
till then.
Second, and orthogonally, this loop has a nested CPR property. There is no
reason that the CPR analyser can't deal with nested stuff, but it doesn't.
There's a nice little project there too.
Either of these would fix this particular example, but both are valuable
in their own right.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2289#comment:3>
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
