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

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

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
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
-- Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
participants (3)
-
Austin Seipp
-
Jan Stolarek
-
Simon Peyton-Jones