32-bit Linux perf failures
Greetings, I just ran validate with current HEAD (2b34947b60069e51abfcada9c45a6d7b590f5a2b) and I have quite a few perf failures. Perhaps these need tweaking? I know that 32-bit numbers were neglected in the past. The Haddock numbers have been complaining for a few weeks now but I think everything else is fairly new. Here is the end of the log: Unexpected results from: TEST="T876 T7954 T8766 T1969 T5631 T783 T3294 haddock.Cabal haddock.compiler haddock.base T3924" OVERALL SUMMARY for test run started at Thu Feb 20 00:54:28 2014 GMT 0:18:11 spent to go through 3903 total tests, which gave rise to 15265 test cases, of which 11699 were skipped 28 had missing libraries 3469 expected passes 58 expected failures 3 caused framework failures 0 unexpected passes 11 unexpected failures Unexpected failures: ../../libraries/base/tests T8766 [stat too good] (normal) callarity/perf T3924 [stat too good] (normal) perf/compiler T1969 [stat too good] (normal) perf/compiler T3294 [stat too good] (normal) perf/compiler T5631 [stat too good] (normal) perf/compiler T783 [stat too good] (normal) perf/haddock haddock.Cabal [stat too good] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat too good] (normal) perf/should_run T7954 [stat too good] (normal) perf/should_run T876 [stat too good] (normal) -- Mateusz K.
Hi, Am Donnerstag, den 20.02.2014, 01:39 +0000 schrieb Mateusz Kowalczyk:
I just ran validate with current HEAD (2b34947b60069e51abfcada9c45a6d7b590f5a2b) and I have quite a few perf failures. Perhaps these need tweaking? I know that 32-bit numbers were neglected in the past. The Haddock numbers have been complaining for a few weeks now but I think everything else is fairly new.
Here is the end of the log:
Unexpected results from: TEST="T876 T7954 T8766 T1969 T5631 T783 T3294 haddock.Cabal haddock.compiler haddock.base T3924"
Call arity has improved T1969, T876, T7954, T3294 and T5631 (so the change for 32bit is expected, just update the numbers to what your computer says) and T3924 was added by my without 32bit numbers (so add your numbers, after adding the usual bitness-switch). Also T4267 is lacking 32-bit numbers. Generally, you might want to run "git blame" on the all.T-files and see if there was a recent change to the 64 bit numbers in the same direction than the change you are observing, and in that case simply update the numbers accordingly. Maybe when changing the 64-bit number we should have a way of marking the i386 as likely out of date, so that the next person on 32bit will see a message „Number changed, but that’s expected, so please just update all.T“. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata@debian.org
On 20/02/14 10:40, Joachim Breitner wrote:
Hi,
Am Donnerstag, den 20.02.2014, 01:39 +0000 schrieb Mateusz Kowalczyk:
I just ran validate with current HEAD (2b34947b60069e51abfcada9c45a6d7b590f5a2b) and I have quite a few perf failures. Perhaps these need tweaking? I know that 32-bit numbers were neglected in the past. The Haddock numbers have been complaining for a few weeks now but I think everything else is fairly new.
Here is the end of the log:
Unexpected results from: TEST="T876 T7954 T8766 T1969 T5631 T783 T3294 haddock.Cabal haddock.compiler haddock.base T3924"
Call arity has improved T1969, T876, T7954, T3294 and T5631 (so the change for 32bit is expected, just update the numbers to what your computer says) and T3924 was added by my without 32bit numbers (so add your numbers, after adding the usual bitness-switch). Also T4267 is lacking 32-bit numbers.
Generally, you might want to run "git blame" on the all.T-files and see if there was a recent change to the 64 bit numbers in the same direction than the change you are observing, and in that case simply update the numbers accordingly.
Maybe when changing the 64-bit number we should have a way of marking the i386 as likely out of date, so that the next person on 32bit will see a message „Number changed, but that’s expected, so please just update all.T“.
Greetings, Joachim
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
While I technically have the push permissions, I'm not a GHC dev. I feel like it'd be inappropriate to push in such a ‘fix’ myself. I can post a full validate log if that contains information one would need to update the numbers. Even if I wanted to, I have no idea how to go about updating the numbers! Is there a guide of some sort available? I was unable to find anything. Thanks -- Mateusz K.
On 2014-02-20 at 16:26:33 +0100, Mateusz Kowalczyk wrote: [...]
While I technically have the push permissions, I'm not a GHC dev. I feel like it'd be inappropriate to push in such a ‘fix’ myself. I can post a full validate log if that contains information one would need to update the numbers.
fyi, the relevant information from the validate log are the parts that looks like: ,---- | =====> T4801(normal) 1527 of 3902 [0, 0, 0] | cd ./perf/compiler && '/workspace/GHC/ghc/bindisttest/install dir/bin/ghc' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T4801.hs +RTS -V0 -tT4801.comp.stats --machine-readable -RTS -static >T4801.comp.stderr 2>&1 | max_bytes_used value is too high: | Expected max_bytes_used: 22646000 +/-10% | Lower bound max_bytes_used: 20381400 | Upper bound max_bytes_used: 24910601 | Actual max_bytes_used: 25113136 | *** unexpected failure for T4801(normal) `----
Even if I wanted to, I have no idea how to go about updating the numbers! Is there a guide of some sort available? I was unable to find anything.
Here's some related information you may have already found yourself (although it does not explain how to actually update the numbers): https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Adding#Performan... The basic idea for updating the numbers though is to find an explaination for the change, and then update the expected range while leaving a comment with the previous value, and when it changed, as well as a note about the reason for the change. You should easily find many examples of that in the testsuite. HTH, hvr
participants (3)
-
Herbert Valerio Riedel -
Joachim Breitner -
Mateusz Kowalczyk