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:ghc-devs-bounces@haskell.org] 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 | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs