AMP performance effect

[Edward Z. Yang]

Hello Joachim,

You are probably seeing the effects of this bug for cryptarithm1:

    https://ghc.haskell.org/trac/ghc/ticket/9570#ticket

Cheers,
Edward

Excerpts from Joachim Breitner's message of 2014-09-12 09:52:14 -0400:
> Hi,
> 
> nothing overly exciting, but since I am running this ghcspeed thing, I
> guess I should inform you about changes, just to get some practice doing
> that :-)
> 
> Due to various build failures, the AMP landing patch was not measured in
> isolation, so these numbers reflect the effect of these patches:
> 
> $ git log fdfe6..1e400 --oneline
> 1e40037 Update nofib submodule to fix errors in main suite.
> 841924c build.mk.sample: Stage1 needn't be built with -fllvm
> 68ecc57 base: replace ver 4.7.1.0 references by 4.8.0.0
> c6f502b Bump `base` version to 4.8.0.0 for real
> 27a642c Revert "base: Bump version to 4.8.0.0"
> 0829f4c base: Bump version to 4.8.0.0
> d94de87 Make Applicative a superclass of Monad
> 
> If you want to have a look yourself, see
> http://ghcspeed-nomeata.rhcloud.com/changes/?rev=1e40037604&exe=2&env=1
> 
> Notable points:
>  * nofib running times are unchanged on average.
>  * binary sizes are consistently reduced by a small amount (-0.7%)
>  * one nofib benchmarks show significant increases in allocation:
>    - cryptalgorithm2 +17,5%
>      Unfortunately, cryptalgorithm’s runtime is below the cut-off, so I 
>      cannot tell if that has changed significantly.
>    - all other nofib benchmarks have unchanged allocation numbers
>  * some testsuite benchmarks as well:
>    - T3064     +28%
>    - T5631     + 7%
>    - T9020     +18%
>    - haddock-* +3%
>    - many with no change at all, some with noise up to +2,7%
> 
> I don’t think this requires action, but if someone feels inclined to
> find out what happened to cryptoalgorithm2 (which uses StateT), feel
> free to give it a shot!
> 
> Greetings,
> Joachim
>