RE: [commit: ghc] master: Bump haddock.base max_bytes_used (8df7fea)
Urk. It's quite surprising that this particular change would increase allocation significantly.
I wonder whether it just pushed it over the threshold.
Simon
| -----Original Message-----
| From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of
| git@git.haskell.org
| Sent: 01 August 2014 18:57
| To: ghc-commits@haskell.org
| Subject: [commit: ghc] master: Bump haddock.base max_bytes_used (8df7fea)
|
| Repository : ssh://git@git.haskell.org/ghc
|
| On branch : master
| Link :
| http://ghc.haskell.org/trac/ghc/changeset/8df7fea7cf8a32d54ac3d6772432273
| 8595bf421/ghc
|
| >---------------------------------------------------------------
|
| commit 8df7fea7cf8a32d54ac3d67724322738595bf421
| Author: Joachim Breitner
Hi, Am Freitag, den 01.08.2014, 20:28 +0000 schrieb Simon Peyton Jones:
Urk. It's quite surprising that this particular change would increase allocation significantly. I wonder whether it just pushed it over the threshold.
I’m confident it was not just that: ~/logs $ fgrep 'Deviation haddock.base(normal) max_bytes_used' $(cd ghc-master; git log --oneline --first-parent db19c665ec5055c2193b2174519866045aeff09a..HEAD | cut -d\ -f1| (cd ..; while read x ; do test -e $x.log && echo $x.log; done) |tac )|tail -n 25 6fa6caa.log: Deviation haddock.base(normal) max_bytes_used: 2.2 % a0ff1eb.log: Deviation haddock.base(normal) max_bytes_used: -1.0 % 0be7c2c.log: Deviation haddock.base(normal) max_bytes_used: 2.2 % dc7d3c2.log: Deviation haddock.base(normal) max_bytes_used: 2.2 % 7381cee.log: Deviation haddock.base(normal) max_bytes_used: 2.2 % fe2d807.log: Deviation haddock.base(normal) max_bytes_used: 2.2 % bfaa179.log: Deviation haddock.base(normal) max_bytes_used: -0.9 % 1ae5fa4.log: Deviation haddock.base(normal) max_bytes_used: 11.0 % c97f853.log: Deviation haddock.base(normal) max_bytes_used: 11.0 % fd47e26.log: Deviation haddock.base(normal) max_bytes_used: 11.2 % bdf0ef0.log: Deviation haddock.base(normal) max_bytes_used: 11.1 % 58ed1cc.log: Deviation haddock.base(normal) max_bytes_used: 11.0 % 1c1ef82.log: Deviation haddock.base(normal) max_bytes_used: 11.2 % 52188ad.log: Deviation haddock.base(normal) max_bytes_used: 11.0 % 3b9fe0c.log: Deviation haddock.base(normal) max_bytes_used: 11.2 % 6483b8a.log: Deviation haddock.base(normal) max_bytes_used: 11.0 % 9d9a554.log: Deviation haddock.base(normal) max_bytes_used: 11.2 % 028630a.log: Deviation haddock.base(normal) max_bytes_used: 11.2 % aab5937.log: Deviation haddock.base(normal) max_bytes_used: 11.0 % 6c06db1.log: Deviation haddock.base(normal) max_bytes_used: 11.0 % 2989ffd.log: Deviation haddock.base(normal) max_bytes_used: 11.1 % d4d4bef.log: Deviation haddock.base(normal) max_bytes_used: 11.2 % 8df7fea.log: Deviation haddock.base(normal) max_bytes_used: -0.0 % 3faff73.log: Deviation haddock.base(normal) max_bytes_used: -0.0 % 02975c9.log: Deviation haddock.base(normal) max_bytes_used: -0.1 % (If this were a bytes_allocated test I could also show you nice graphs like http://ghcspeed-nomeata.rhcloud.com/timeline/?exe=2&base=2% 2B68&ben=tests%2Falloc%2FT6048&env=1&revs=50&equid=on but I didn’t add the max_bytes_used tests yet.) Interestingly, bytes_allocated did not change a bit! 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
Hi, Am Freitag, den 01.08.2014, 23:27 +0200 schrieb Joachim Breitner:
Am Freitag, den 01.08.2014, 20:28 +0000 schrieb Simon Peyton Jones:
Urk. It's quite surprising that this particular change would increase allocation significantly. I wonder whether it just pushed it over the threshold.
I’m confident it was not just that:
~/logs $ fgrep 'Deviation haddock.base(normal) max_bytes_used' $(cd ghc-master; git log --oneline --first-parent db19c665ec5055c2193b2174519866045aeff09a..HEAD | cut -d\ -f1| (cd ..; while read x ; do test -e $x.log && echo $x.log; done) |tac )|tail -n 25 6fa6caa.log: Deviation haddock.base(normal) max_bytes_used: 2.2 % a0ff1eb.log: Deviation haddock.base(normal) max_bytes_used: -1.0 % 0be7c2c.log: Deviation haddock.base(normal) max_bytes_used: 2.2 % dc7d3c2.log: Deviation haddock.base(normal) max_bytes_used: 2.2 % 7381cee.log: Deviation haddock.base(normal) max_bytes_used: 2.2 % fe2d807.log: Deviation haddock.base(normal) max_bytes_used: 2.2 % bfaa179.log: Deviation haddock.base(normal) max_bytes_used: -0.9 % 1ae5fa4.log: Deviation haddock.base(normal) max_bytes_used: 11.0 % c97f853.log: Deviation haddock.base(normal) max_bytes_used: 11.0 % fd47e26.log: Deviation haddock.base(normal) max_bytes_used: 11.2 % bdf0ef0.log: Deviation haddock.base(normal) max_bytes_used: 11.1 % [..]
Interestingly, bytes_allocated did not change a bit!
your surprise made me investigate further. Could this have been caused by this change to how I run the testsuite, which I did roughly around that time? -run make -C testsuite fast VERBOSE=4 THREADS=8 +run make -C testsuite fast VERBOSE=4 THREADS=8 NoFibRuns=15 .... No, no difference. But the value changed again: d4d4bef.log: Deviation haddock.base(normal) max_bytes_used: 11.2 % 8df7fea.log: Deviation haddock.base(normal) max_bytes_used: -0.0 % 3faff73.log: Deviation haddock.base(normal) max_bytes_used: -0.0 % 0336588.log: Deviation haddock.base(normal) max_bytes_used: -0.2 % 02975c9.log: Deviation haddock.base(normal) max_bytes_used: -0.1 % 578fbec.log: Deviation haddock.base(normal) max_bytes_used: -0.2 % e69619e.log: Deviation haddock.base(normal) max_bytes_used: 0.0 % 105602f.log: Deviation haddock.base(normal) max_bytes_used: -0.2 % fbd0586.log: Deviation haddock.base(normal) max_bytes_used: -6.5 % ab90bf2.log: Deviation haddock.base(normal) max_bytes_used: -6.5 % f293931.log: Deviation haddock.base(normal) max_bytes_used: -6.6 % and fbd0586 really looks harmless. Not sure what is going on here. I find the changes to be too big (and within a certain range of commits too deterministic) to be just the consequence of RTS timer noise. 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
Ha. max_bytes_used is vulnerable to exactly when gc strikes, so I'm disinclined to get stressed about this. I was mis-reading it as bytes-allocated. Interestingly it doesn't happen for me. Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | Joachim Breitner | Sent: 01 August 2014 22:27 | To: ghc-devs@haskell.org | Subject: Re: [commit: ghc] master: Bump haddock.base max_bytes_used | (8df7fea) | | Hi, | | | Am Freitag, den 01.08.2014, 20:28 +0000 schrieb Simon Peyton Jones: | > Urk. It's quite surprising that this particular change would | increase allocation significantly. | > I wonder whether it just pushed it over the threshold. | | I’m confident it was not just that: | | ~/logs $ fgrep 'Deviation haddock.base(normal) max_bytes_used' $(cd | ghc-master; git log --oneline --first-parent | db19c665ec5055c2193b2174519866045aeff09a..HEAD | cut -d\ -f1| (cd ..; | while read x ; do test -e $x.log && echo $x.log; done) |tac )|tail -n | 25 | 6fa6caa.log: Deviation haddock.base(normal) max_bytes_used: | 2.2 % | a0ff1eb.log: Deviation haddock.base(normal) max_bytes_used: - | 1.0 % | 0be7c2c.log: Deviation haddock.base(normal) max_bytes_used: | 2.2 % | dc7d3c2.log: Deviation haddock.base(normal) max_bytes_used: | 2.2 % | 7381cee.log: Deviation haddock.base(normal) max_bytes_used: | 2.2 % | fe2d807.log: Deviation haddock.base(normal) max_bytes_used: | 2.2 % | bfaa179.log: Deviation haddock.base(normal) max_bytes_used: - | 0.9 % | 1ae5fa4.log: Deviation haddock.base(normal) max_bytes_used: | 11.0 % | c97f853.log: Deviation haddock.base(normal) max_bytes_used: | 11.0 % | fd47e26.log: Deviation haddock.base(normal) max_bytes_used: | 11.2 % | bdf0ef0.log: Deviation haddock.base(normal) max_bytes_used: | 11.1 % | 58ed1cc.log: Deviation haddock.base(normal) max_bytes_used: | 11.0 % | 1c1ef82.log: Deviation haddock.base(normal) max_bytes_used: | 11.2 % | 52188ad.log: Deviation haddock.base(normal) max_bytes_used: | 11.0 % | 3b9fe0c.log: Deviation haddock.base(normal) max_bytes_used: | 11.2 % | 6483b8a.log: Deviation haddock.base(normal) max_bytes_used: | 11.0 % | 9d9a554.log: Deviation haddock.base(normal) max_bytes_used: | 11.2 % | 028630a.log: Deviation haddock.base(normal) max_bytes_used: | 11.2 % | aab5937.log: Deviation haddock.base(normal) max_bytes_used: | 11.0 % | 6c06db1.log: Deviation haddock.base(normal) max_bytes_used: | 11.0 % | 2989ffd.log: Deviation haddock.base(normal) max_bytes_used: | 11.1 % | d4d4bef.log: Deviation haddock.base(normal) max_bytes_used: | 11.2 % | 8df7fea.log: Deviation haddock.base(normal) max_bytes_used: - | 0.0 % | 3faff73.log: Deviation haddock.base(normal) max_bytes_used: - | 0.0 % | 02975c9.log: Deviation haddock.base(normal) max_bytes_used: - | 0.1 % | | | (If this were a bytes_allocated test I could also show you nice graphs | like http://ghcspeed-nomeata.rhcloud.com/timeline/?exe=2&base=2% | 2B68&ben=tests%2Falloc%2FT6048&env=1&revs=50&equid=on but I didn’t add | the max_bytes_used tests yet.) | | Interestingly, bytes_allocated did not change a bit! | | 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
Yes, on my box, this test is now failing (because the stat is too good): Expected haddock.base(normal) max_bytes_used: 127954488 +/-10% Lower bound haddock.base(normal) max_bytes_used: 115159039 Upper bound haddock.base(normal) max_bytes_used: 140749937 Actual haddock.base(normal) max_bytes_used: 113167424 Deviation haddock.base(normal) max_bytes_used: -11.6 % Cheers, Edward Excerpts from Simon Peyton Jones's message of 2014-08-04 08:21:50 +0100:
Ha. max_bytes_used is vulnerable to exactly when gc strikes, so I'm disinclined to get stressed about this. I was mis-reading it as bytes-allocated. Interestingly it doesn't happen for me.
Simon
| -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | Joachim Breitner | Sent: 01 August 2014 22:27 | To: ghc-devs@haskell.org | Subject: Re: [commit: ghc] master: Bump haddock.base max_bytes_used | (8df7fea) | | Hi, | | | Am Freitag, den 01.08.2014, 20:28 +0000 schrieb Simon Peyton Jones: | > Urk. It's quite surprising that this particular change would | increase allocation significantly. | > I wonder whether it just pushed it over the threshold. | | I’m confident it was not just that: | | ~/logs $ fgrep 'Deviation haddock.base(normal) max_bytes_used' $(cd | ghc-master; git log --oneline --first-parent | db19c665ec5055c2193b2174519866045aeff09a..HEAD | cut -d\ -f1| (cd ..; | while read x ; do test -e $x.log && echo $x.log; done) |tac )|tail -n | 25 | 6fa6caa.log: Deviation haddock.base(normal) max_bytes_used: | 2.2 % | a0ff1eb.log: Deviation haddock.base(normal) max_bytes_used: - | 1.0 % | 0be7c2c.log: Deviation haddock.base(normal) max_bytes_used: | 2.2 % | dc7d3c2.log: Deviation haddock.base(normal) max_bytes_used: | 2.2 % | 7381cee.log: Deviation haddock.base(normal) max_bytes_used: | 2.2 % | fe2d807.log: Deviation haddock.base(normal) max_bytes_used: | 2.2 % | bfaa179.log: Deviation haddock.base(normal) max_bytes_used: - | 0.9 % | 1ae5fa4.log: Deviation haddock.base(normal) max_bytes_used: | 11.0 % | c97f853.log: Deviation haddock.base(normal) max_bytes_used: | 11.0 % | fd47e26.log: Deviation haddock.base(normal) max_bytes_used: | 11.2 % | bdf0ef0.log: Deviation haddock.base(normal) max_bytes_used: | 11.1 % | 58ed1cc.log: Deviation haddock.base(normal) max_bytes_used: | 11.0 % | 1c1ef82.log: Deviation haddock.base(normal) max_bytes_used: | 11.2 % | 52188ad.log: Deviation haddock.base(normal) max_bytes_used: | 11.0 % | 3b9fe0c.log: Deviation haddock.base(normal) max_bytes_used: | 11.2 % | 6483b8a.log: Deviation haddock.base(normal) max_bytes_used: | 11.0 % | 9d9a554.log: Deviation haddock.base(normal) max_bytes_used: | 11.2 % | 028630a.log: Deviation haddock.base(normal) max_bytes_used: | 11.2 % | aab5937.log: Deviation haddock.base(normal) max_bytes_used: | 11.0 % | 6c06db1.log: Deviation haddock.base(normal) max_bytes_used: | 11.0 % | 2989ffd.log: Deviation haddock.base(normal) max_bytes_used: | 11.1 % | d4d4bef.log: Deviation haddock.base(normal) max_bytes_used: | 11.2 % | 8df7fea.log: Deviation haddock.base(normal) max_bytes_used: - | 0.0 % | 3faff73.log: Deviation haddock.base(normal) max_bytes_used: - | 0.0 % | 02975c9.log: Deviation haddock.base(normal) max_bytes_used: - | 0.1 % | | | (If this were a bytes_allocated test I could also show you nice graphs | like http://ghcspeed-nomeata.rhcloud.com/timeline/?exe=2&base=2% | 2B68&ben=tests%2Falloc%2FT6048&env=1&revs=50&equid=on but I didn’t add | the max_bytes_used tests yet.) | | Interestingly, bytes_allocated did not change a bit! | | 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
This is also happening on Phabricator, which is causing the buildbot to choke:
https://phabricator.haskell.org/D112#4
On Mon, Aug 4, 2014 at 6:02 AM, Edward Z. Yang
Yes, on my box, this test is now failing (because the stat is too good):
Expected haddock.base(normal) max_bytes_used: 127954488 +/-10% Lower bound haddock.base(normal) max_bytes_used: 115159039 Upper bound haddock.base(normal) max_bytes_used: 140749937 Actual haddock.base(normal) max_bytes_used: 113167424 Deviation haddock.base(normal) max_bytes_used: -11.6 %
Cheers, Edward
Excerpts from Simon Peyton Jones's message of 2014-08-04 08:21:50 +0100:
Ha. max_bytes_used is vulnerable to exactly when gc strikes, so I'm disinclined to get stressed about this. I was mis-reading it as bytes-allocated. Interestingly it doesn't happen for me.
Simon
| -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | Joachim Breitner | Sent: 01 August 2014 22:27 | To: ghc-devs@haskell.org | Subject: Re: [commit: ghc] master: Bump haddock.base max_bytes_used | (8df7fea) | | Hi, | | | Am Freitag, den 01.08.2014, 20:28 +0000 schrieb Simon Peyton Jones: | > Urk. It's quite surprising that this particular change would | increase allocation significantly. | > I wonder whether it just pushed it over the threshold. | | I’m confident it was not just that: | | ~/logs $ fgrep 'Deviation haddock.base(normal) max_bytes_used' $(cd | ghc-master; git log --oneline --first-parent | db19c665ec5055c2193b2174519866045aeff09a..HEAD | cut -d\ -f1| (cd ..; | while read x ; do test -e $x.log && echo $x.log; done) |tac )|tail -n | 25 | 6fa6caa.log: Deviation haddock.base(normal) max_bytes_used: | 2.2 % | a0ff1eb.log: Deviation haddock.base(normal) max_bytes_used: - | 1.0 % | 0be7c2c.log: Deviation haddock.base(normal) max_bytes_used: | 2.2 % | dc7d3c2.log: Deviation haddock.base(normal) max_bytes_used: | 2.2 % | 7381cee.log: Deviation haddock.base(normal) max_bytes_used: | 2.2 % | fe2d807.log: Deviation haddock.base(normal) max_bytes_used: | 2.2 % | bfaa179.log: Deviation haddock.base(normal) max_bytes_used: - | 0.9 % | 1ae5fa4.log: Deviation haddock.base(normal) max_bytes_used: | 11.0 % | c97f853.log: Deviation haddock.base(normal) max_bytes_used: | 11.0 % | fd47e26.log: Deviation haddock.base(normal) max_bytes_used: | 11.2 % | bdf0ef0.log: Deviation haddock.base(normal) max_bytes_used: | 11.1 % | 58ed1cc.log: Deviation haddock.base(normal) max_bytes_used: | 11.0 % | 1c1ef82.log: Deviation haddock.base(normal) max_bytes_used: | 11.2 % | 52188ad.log: Deviation haddock.base(normal) max_bytes_used: | 11.0 % | 3b9fe0c.log: Deviation haddock.base(normal) max_bytes_used: | 11.2 % | 6483b8a.log: Deviation haddock.base(normal) max_bytes_used: | 11.0 % | 9d9a554.log: Deviation haddock.base(normal) max_bytes_used: | 11.2 % | 028630a.log: Deviation haddock.base(normal) max_bytes_used: | 11.2 % | aab5937.log: Deviation haddock.base(normal) max_bytes_used: | 11.0 % | 6c06db1.log: Deviation haddock.base(normal) max_bytes_used: | 11.0 % | 2989ffd.log: Deviation haddock.base(normal) max_bytes_used: | 11.1 % | d4d4bef.log: Deviation haddock.base(normal) max_bytes_used: | 11.2 % | 8df7fea.log: Deviation haddock.base(normal) max_bytes_used: - | 0.0 % | 3faff73.log: Deviation haddock.base(normal) max_bytes_used: - | 0.0 % | 02975c9.log: Deviation haddock.base(normal) max_bytes_used: - | 0.1 % | | | (If this were a bytes_allocated test I could also show you nice graphs | like http://ghcspeed-nomeata.rhcloud.com/timeline/?exe=2&base=2% | 2B68&ben=tests%2Falloc%2FT6048&env=1&revs=50&equid=on but I didn’t add | the max_bytes_used tests yet.) | | Interestingly, bytes_allocated did not change a bit! | | 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
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
OK, so perhaps we should just bump the limit? max_bytes_used is an unreliable meause
| -----Original Message-----
| From: mad.one@gmail.com [mailto:mad.one@gmail.com] On Behalf Of Austin
| Seipp
| Sent: 04 August 2014 12:04
| To: Edward Z. Yang
| Cc: Simon Peyton Jones; Joachim Breitner; ghc-devs@haskell.org
| Subject: Re: [commit: ghc] master: Bump haddock.base max_bytes_used
| (8df7fea)
|
| This is also happening on Phabricator, which is causing the buildbot to
| choke:
|
| https://phabricator.haskell.org/D112#4
|
| On Mon, Aug 4, 2014 at 6:02 AM, Edward Z. Yang
Hi, Am Montag, den 04.08.2014, 12:02 +0100 schrieb Edward Z.Yang:
Yes, on my box, this test is now failing (because the stat is too good):
Expected haddock.base(normal) max_bytes_used: 127954488 +/-10% Lower bound haddock.base(normal) max_bytes_used: 115159039 Upper bound haddock.base(normal) max_bytes_used: 140749937 Actual haddock.base(normal) max_bytes_used: 113167424 Deviation haddock.base(normal) max_bytes_used: -11.6 %
ugh. What are your compilation settings? Plain "validate"? Looks like the ghcspeed instance settings still don’t quite match what validate does... But I don’t see anything in mk/validate-settings.mk which would yield different results than echo 'GhcLibHcOpts += -O -dcore-lint' >> mk/build.mk echo 'GhcStage2HcOpts += -O -dcore-lint' >> mk/build.mk I’m starting a plain validate run on that machine, to see if it is compilation settings or some other variable. 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
Hi, Am Montag, den 04.08.2014, 13:08 +0200 schrieb Joachim Breitner:
Am Montag, den 04.08.2014, 12:02 +0100 schrieb Edward Z.Yang:
Yes, on my box, this test is now failing (because the stat is too good):
Expected haddock.base(normal) max_bytes_used: 127954488 +/-10% Lower bound haddock.base(normal) max_bytes_used: 115159039 Upper bound haddock.base(normal) max_bytes_used: 140749937 Actual haddock.base(normal) max_bytes_used: 113167424 Deviation haddock.base(normal) max_bytes_used: -11.6 %
ugh.
What are your compilation settings? Plain "validate"?
Looks like the ghcspeed instance settings still don’t quite match what validate does...
But I don’t see anything in mk/validate-settings.mk which would yield different results than echo 'GhcLibHcOpts += -O -dcore-lint' >> mk/build.mk echo 'GhcStage2HcOpts += -O -dcore-lint' >> mk/build.mk
I’m starting a plain validate run on that machine, to see if it is compilation settings or some other variable.
validate goes through without a problem. So it seems to be dependent on other things. Are these very flaky measures (max_bytes_used) at all useful? So far, I have only seen friction due to them, and any real problem would likely be caught by either bytes_allocated or nofib measurements (I hope). Maybe we should simply remove them from the test suite, and stop worrying? 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 04/08/2014 13:13, Joachim Breitner wrote:
Hi,
Am Montag, den 04.08.2014, 13:08 +0200 schrieb Joachim Breitner:
Am Montag, den 04.08.2014, 12:02 +0100 schrieb Edward Z.Yang:
Yes, on my box, this test is now failing (because the stat is too good):
Expected haddock.base(normal) max_bytes_used: 127954488 +/-10% Lower bound haddock.base(normal) max_bytes_used: 115159039 Upper bound haddock.base(normal) max_bytes_used: 140749937 Actual haddock.base(normal) max_bytes_used: 113167424 Deviation haddock.base(normal) max_bytes_used: -11.6 %
ugh.
What are your compilation settings? Plain "validate"?
Looks like the ghcspeed instance settings still don’t quite match what validate does...
But I don’t see anything in mk/validate-settings.mk which would yield different results than echo 'GhcLibHcOpts += -O -dcore-lint' >> mk/build.mk echo 'GhcStage2HcOpts += -O -dcore-lint' >> mk/build.mk
I’m starting a plain validate run on that machine, to see if it is compilation settings or some other variable.
validate goes through without a problem. So it seems to be dependent on other things.
Are these very flaky measures (max_bytes_used) at all useful? So far, I have only seen friction due to them, and any real problem would likely be caught by either bytes_allocated or nofib measurements (I hope). Maybe we should simply remove them from the test suite, and stop worrying?
From testsuite/tests/perf/compiler/all.T: # Note [residency] # # Residency (peak_megabytes_allocated and max_bytes_used) is sensitive # to when the major GC runs, which makes it inherently inaccurate. # Sometime an innocuous change somewhere can shift things around such # that the samples occur at a different time, and the residency # appears to change (up or down) when the underlying profile hasn't # really changed. # # However, please don't just ignore changes in residency. If you see # a change in one of these figures, please check whether it is real or # not as follows: # # * Run the test with old and new compilers, adding +RTS -h -i0.01 # (you don't need to compile anything for profiling or enable profiling # libraries to get a heap profile). # * view the heap profiles, read off the maximum residency. If it has # really changed, then you know there's an issue. This advice is hard to follow for the Haddock tests, because the test doesn't actually run anything, it just uses the information previously collected. I think we should probably remove the max_bytes_used limits for the Haddock tests. Cheers, Simon
Yes, plain validate. Cheers, Edward Excerpts from Joachim Breitner's message of 2014-08-04 12:08:31 +0100:
Hi,
Am Montag, den 04.08.2014, 12:02 +0100 schrieb Edward Z.Yang:
Yes, on my box, this test is now failing (because the stat is too good):
Expected haddock.base(normal) max_bytes_used: 127954488 +/-10% Lower bound haddock.base(normal) max_bytes_used: 115159039 Upper bound haddock.base(normal) max_bytes_used: 140749937 Actual haddock.base(normal) max_bytes_used: 113167424 Deviation haddock.base(normal) max_bytes_used: -11.6 %
ugh.
What are your compilation settings? Plain "validate"?
Looks like the ghcspeed instance settings still don’t quite match what validate does...
But I don’t see anything in mk/validate-settings.mk which would yield different results than echo 'GhcLibHcOpts += -O -dcore-lint' >> mk/build.mk echo 'GhcStage2HcOpts += -O -dcore-lint' >> mk/build.mk
I’m starting a plain validate run on that machine, to see if it is compilation settings or some other variable.
Greetings, Joachim
On 08/04/2014 01:08 PM, Joachim Breitner wrote:
Hi,
Am Montag, den 04.08.2014, 12:02 +0100 schrieb Edward Z.Yang:
Yes, on my box, this test is now failing (because the stat is too good):
Expected haddock.base(normal) max_bytes_used: 127954488 +/-10% Lower bound haddock.base(normal) max_bytes_used: 115159039 Upper bound haddock.base(normal) max_bytes_used: 140749937 Actual haddock.base(normal) max_bytes_used: 113167424 Deviation haddock.base(normal) max_bytes_used: -11.6 %
ugh.
What are your compilation settings? Plain "validate"?
Looks like the ghcspeed instance settings still don’t quite match what validate does...
But I don’t see anything in mk/validate-settings.mk which would yield different results than echo 'GhcLibHcOpts += -O -dcore-lint' >> mk/build.mk echo 'GhcStage2HcOpts += -O -dcore-lint' >> mk/build.mk
I’m starting a plain validate run on that machine, to see if it is compilation settings or some other variable.
Greetings, Joachim
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
I'd like to point out that on my 32-bit box, I don't remember the last time Haddock perf numbers passed the validation even if I see commits updating them. See [1] for an example. [1]: http://haskell.inf.elte.hu/builders/validator1-linux-x86-head/43.html -- Mateusz K.
participants (6)
-
Austin Seipp -
Edward Z. Yang -
Joachim Breitner -
Mateusz Kowalczyk -
Simon Marlow -
Simon Peyton Jones