Perf on T10858

[Joachim Breitner]

Hi,

Am Donnerstag, den 20.10.2016, 10:20 -0400 schrieb Ben Gamari:
> > Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:
> 
> > I’m getting this on HEAD on my Linux box (64 bit)
> > 
> > cd "./perf/T10858.run" &&  "/5playpen/simonpj/HEAD-2/inplace/test   spaces/ghc-stage2" -c T10858.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -dno-debug-output  -O +RTS -V0 -tT10858.comp.stats --machine-readable -RTS
> > 
> > bytes allocated value is too low:
> > 
> > (If this is because you have improved GHC, please
> > 
> > update the test so that GHC doesn't regress again)
> > 
> >     Expected    T10858(normal) bytes allocated: 241655120 +/-8%
> > 
> >     Lower bound T10858(normal) bytes allocated: 222322710
> > 
> >     Upper bound T10858(normal) bytes allocated: 260987530
> > 
> >     Actual      T10858(normal) bytes allocated: 221938928
> > 
> >     Deviation   T10858(normal) bytes allocated:      -8.2 %
> > 
> > Does anyone else?  It’s good – but why isn’t Harbormaster complaining?
> > 
> 
> A very good question. It looks like the result is straddling the edge of
> acceptable so it's conceivable that Harbormaster is (for some reason)
> just below the failing threshold. We've seen this sort of small
> non-determinism in allocations in the past, although I don't have a
> compelling explanation for why.

this is confirmed here:
https://perf.haskell.org/ghc/#graph/tests/alloc/T10858
It is close to the lower edge, and not 100% stable.



Greetings,
Joachim


-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20161020/2c1ebb00/attachment.sig>