Re: 32-bit Linux perf failures
Hi, Am Donnerstag, den 20.02.2014, 01:39 + 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 m...@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nome...@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 32-bit Linux perf failures
On 20/02/14 10:40, Joachim Breitner wrote: Hi, Am Donnerstag, den 20.02.2014, 01:39 + 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. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: 32-bit Linux perf failures
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 21 | max_bytes_used value is too high: | Expectedmax_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#Performancetests 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
