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