32-bit Linux perf failures

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

32-bit Linux perf failures

Mateusz Kowalczyk
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.

Reply | Threaded
Open this post in threaded view
|

32-bit Linux perf failures

Joachim Breitner-2
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 at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140220/4c510b2d/attachment.sig>

Reply | Threaded
Open this post in threaded view
|

32-bit Linux perf failures

Mateusz Kowalczyk
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 at 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.

Reply | Threaded
Open this post in threaded view
|

32-bit Linux perf failures

Herbert Valerio Riedel-3
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#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