Experiment with GC options

[Boarders]

The user guide gives various options for runtime parameters particularly for tuning the garbage collector. We should experiment with changing the allocation area of the program to see if this makes a difference to our runtimes. This is done as follows:
./pcg +RTS -A1G -RTS
The above command sets the allocation area to be 1GB. By default it is 1MB. We should see what settings seem to work best for a longer running example. The example here received a 3-6 times speed up from this change and so it is well worth looking into.

Similarly there are settings for the number of generations in the garbage collector. This can be changed as follows:
./pcg +RTS -G4 -RTS
By default this is set at 2 and it is recommended in the user guide to not exceed 4. When we upgrade to GHC 8.10 we can also experiment with the new concurrent garbage collector which can be ran by compiling with threaded and using the run time options:
./pcg +RTS -xn -RTS

[Boarders]

Just as a (not necessarily informative) data point, running a Wagner build 100 times has the following numbers:

> time ./pcg < chel.pcg
real	1m6.747s
user	1m6.289s
sys	0m0.533s

> time ./pcg < chel.pcg  +RTS -A1G -RTS
real	0m56.338s
user	0m55.888s
sys	0m0.553s

It might be worth having this as the default option.

[recursion-ninja]

Looks to be around 10% faster. That's an effortless yet significant improvement!

[Boarders]

I should note that the parallel garbage collector led to a regression on the workloads I tried but perhaps something more memory intensive will fit better.

[recursion-ninja]

If someone wants to spend a few more days toying with GC options after ghc-9.0 is released, that would be a valuable time investment. We can take the apparently best GC options and set them as the defaults when compiling our pcg executable using the -with-rtsopts compilation flag.