Hi,

Am Donnerstag, den 20.10.2016, 10:20 -0400 schrieb Ben Gamari:
> > Simon Peyton Jones via ghc-devs <[email protected]> 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
  [email protected]https://www.joachim-breitner.de/
  XMPP: [email protected] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [email protected]

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
ghc-devs mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Reply via email to