Yes, they wibbled for me a little during the patch. I figured we could tighten them actually, but peak_megabytes is particularly fiddly I've found as Simon said.
On Thu, Sep 12, 2013 at 12:02 PM, Simon Peyton-Jones <[email protected]> wrote: > This test wobbles around a lot, as a glance at all.T will show. > peak-megabytes is very vulnerable to changes in when GC strikes. I suggest > just changing the numbers to accept > > S > > | -----Original Message----- > | From: ghc-devs [mailto:[email protected]] On Behalf Of Jan > Stolarek > | Sent: 12 September 2013 17:58 > | To: ghc-devs > | Cc: Austin Seipp > | Subject: AMP patch and performance tests failures > | > | I am getting validation failures from T3064 performance test: > | > | =====> T3064(normal) 1741 of 3782 [0, 0, 0] > | cd ./perf/compiler && > '/5playpen/t-jastol/ghc-validate/inplace/bin/ghc-stage2' - > | fforce-recomp -dno-debug-output -no-user-package-db -rtsopts > -fno-ghci-history > | -c T3064.hs +RTS -V0 -tT3064.comp.stats --machine-readable -RTS > | >T3064.comp.stderr 2>&1 > | peak_megabytes_allocated value is too high: > | Expected peak_megabytes_allocated: 30 +/-20% > | Lower bound peak_megabytes_allocated: 24 > | Upper bound peak_megabytes_allocated: 36 > | Actual peak_megabytes_allocated: 39 > | > | This tests has some instances of Monads and Applicatives so my random > guess is > | that AMP patch caused that. Can anyone working on that patch confirm or > deny > | that it increases allocation and causes this failure? I also got a > validation failure > | from T5837 a couple of times, but it doesn't happen always. > | > | Janek > | _______________________________________________ > | ghc-devs mailing list > | [email protected] > | http://www.haskell.org/mailman/listinfo/ghc-devs -- Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
