Possible loss of sharing: big performance change

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.

Trac metadata

Trac field	Value
Version	7.0.3
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture