#5068: Possible loss of sharing: big performance change
---------------------------------+------------------------------------------
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.0.3
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Bryan's blog post http://www.serpentine.com/blog/2011/03/18/a-little-care-
and-feeding-can-go-a-long-way/ said that he got a massive performance
change by changing some INLINE pragmas. GHC shouldn't ''ever'' duplicate
work, as he implies: "causing the ziggurat tables to be regenerated over
and over instead of precomputed just once".
Bryan writes: here's the changeset that shows exactly what I did.
https://bitbucket.org/bos/mwc-random/changeset/123ccdb62a3a
I'm using the vector package here, imported under the name I, to compute
the "blocks" and "ratios" values, the two vectors I've marked as NOINLINE.
These only need to be computed once, but the majority of the speed
improvement I allude to in the blog post comes from marking them as
NOINLINE (the other two INLINE annotations account for a few percent
improvement, which is nice, but not a big deal).
Now, I'll confess that (for once) I didn't read the Core generated before
and after to see if it was some *other* consequence of those pragmas that
led to the speedups. It's possible that I misattributed the speedups to
the recomputation of those vectors, when in fact something else was at
work.
Bryan is going to get around to more detailed repro instructions; and
perhaps glance at the core first to see if ‘ratios` or ‘defaultSeed` are
getting inlined inside a lambda. This ticket is just to keep it on our
radar.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5068>
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
