#1216: Missed opportunity for let-no-esape
--------------------------------------+-------------------------------------
Reporter: claus | Owner: simonpj
Type: bug | Status: new
Priority: normal | Milestone: 6.12 branch
Component: Compiler | Version: 6.6
Resolution: | Keywords:
Difficulty: Unknown | Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: Runtime performance bug |
--------------------------------------+-------------------------------------
Changes (by simonpj):
* summary: indexing 2d arrays is slow and leaky. why? => Missed
opportunity for let-no-esape
Comment:
I've finally gotten around to this, but only in HEAD. It's all to do with
inlining array indexing, and doing so without causing grotesque code bloat
from copied error messages.
The key things are
* Adding INLINE pragmas to `index` in `GHC.Arr`.
* Floating out error message code (the bottom-extraction patch)
Results.
{{{
index is Allocation Elapsed time
--------------------------------------------------------
GHC 6.10 local 19M 1.68s
library 14,000M 8.73s
HEAD local 16M 1.78s
library 18M 1.52s
}}}
By "index is local" I mean that we use the locally-defined `myIndex`. By
"library" I mean that `myIndex` is set equal to `index` so we use the
overloaded `index` from `GHC.Arr`. (I think the allocation is higher than
in the figures above because I'm measuring on a 64-bit machine.)
So now the naive code is fastest. I'm not quite sure why the 'local'
version in HEAD is slower than the 'library' version, but I've spent
enough time on this.
Wed Dec 16 17:04:41 GMT 2009 [email protected]
The library patch is this:
{{{
* Mark 'index' as INLINE in GHC.Arr
This makes indexing much faster. See Trac #1216
}}}
However I'm leaving the ticket open because I see that the inner loop
shows the same phenomenon as #3458: we could greatly reduce allocation by
pushing the binding for a local function to nearer its call site (in the
scrutinee of a case).
I'll re-title the ticket though.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1216#comment:17>
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
