Check effect of shrinking on non-moving collector

[treeowl]

When the non-moving garbage collector is in use, each shrink operation has to do some funny business to support it. How expensive is this? Is it expensive enough to justify cloning instead, especially for very small arrays?

[treeowl]

@bgamari, your input would be very much appreciated.

[sjakobi]

To provide a single datapoint: The 8% speedup as a result of using shrink in filterMapAux (#433) was measured with -nonmoving-gc:

unordered-containers/unordered-containers.cabal

Lines 138 to 139 in fe33c60

	if impl(ghc >= 8.10)
	ghc-options: "-with-rtsopts=-A32m --nonmoving-gc"

When the non-moving garbage collector is in use, each shrink operation has to do some funny business to support it.

Roughly what is this funny business? I'm very unfamiliar with how the non-moving GC works.

[treeowl]

Roughly, I have no idea. I just saw calls to some functions or macros in the cmm definition of the shrinking primop. How did it do with the copying collector?

[sjakobi]

How did it do with the copying collector?

I didn't try that. Something like cabal run benches -- -p filterWithKey --stdev 0.5 should do the trick.

[treeowl]

It would be interesting to see, but shrinking is pretty much totally free with that collector, so I imagine the improvements would be even larger.

[treeowl]

If the code was faster than before when you tested with the non-moving collector, I think we can close this.

[sjakobi]

Alright.