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 -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
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
Hi, Am Freitag, den 12.09.2014, 10:00 -0400 schrieb Edward Z. Yang:
You are probably seeing the effects of this bug for cryptarithm1:
possibly. But you report runtime differences without changes in allocation numbers, whereas I observed changes in allocation numbers. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
On Fri, Sep 12, 2014 at 3:52 PM, Joachim Breitner
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 :-)
I'm very much in support of doing this. Once we think pagespeed is stable enough, I would be for sending automated emails on regressions. If you need a different machine to host it, you can reach out to admin@haskell.org. If they don't have one, I have a quiet quite powerful machine in a data center.
Hi, Am Freitag, den 12.09.2014, 16:10 +0200 schrieb Johan Tibell:
Once we think pagespeed is stable enough, I would be for sending automated emails on regressions.
it is quite noisy, which is mostly due to the fact that I track the „number of failing testcases“ as a performance value, which regularly goes +∞ (e.g. from 0 to 1). I’m still worried about sending mails out, but interested parties are welcome to subscribe to the RSS feed at http://ghcspeed-nomeata.rhcloud.com/feeds/latest_significant/ Also, ghcspeed has no support for sending mails yet, so we would either have to add that or use the RSS feed with some RSS-to-mail tool.
If you need a different machine to host it, you can reach out to admin@haskell.org. If they don't have one, I have a quiet quite powerful machine in a data center.
During ICFP, Ryan Newton also offered me a machine. We can actually start using a new maching while keeping the old one running, codespeed allows to distinguish between them. So let’s start on this: Either give me a user account somewhere, or – as it is simple – try it yourself using the scripts in https://github.com/nomeata/codespeed/tree/ghc/tools/ghc (maybe while I’m in IRC or so). Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
participants (3)
-
Edward Z. Yang -
Joachim Breitner -
Johan Tibell