[Diffusion] [Raised Concern] rGHC751996e90a96: Kill off complications in CoreFVs

Joachim Breitner mail at joachim-breitner.de
Thu Apr 13 15:24:05 UTC 2017


[CC’ing ghc-dev in case others are also curious about how to navigate Gipeda.]

Hi,


Am Donnerstag, den 13.04.2017, 08:40 +0000 schrieb Simon Peyton Jones:
> Thanks for noticing this!  I will investigate.
>  
> But where do you see this?
> ·         at perf.haskell.org I see “GHC” and “Gipeda”.  It’s not 
>           obvious which I want.

You want the GHC Dashboard, as you guessed correctly.

> ·         Clicking GHC shows me some “recent commits”.  The first
> three are from a few hrs ago; then the next is 8 days ago. Can’t be
> right!

It only shows interesting commits. Interesting ones are the most recent
ones and all with significant changes. If you want to see all, press
the “=” button in the top-right corner.

> ·         There is no key to tell me what the little symbols mean – I
> may have known once but I don’t know.  A key would be terrific, or
> even a link to a key.

The symbols next to the three numbers on the right in the table? They
are:
 * number of benchmarks
 * number of benchmarks improved
 * number of benchmarks regressed
Maybe I should remove the first one, it is not very useful

Hovering these icons show you which benchmarks changed, and by how
much.

> ·         Clicking on the offending patch (which does show), I see
> the n-body complaint, which is good.  But there is also
> “testsuite/unexpected stats, which is mysterious… clicking on it
> yields no more info.

There is a “view buildlog” link that I use to investigate such cases.
It goes to
https://raw.githubusercontent.com/nomeata/ghc-speed-logs/master/751996e90a964026a3f86853338f10c82db6b610.log
which shows

bytes allocated value is too low:
(If this is because you have improved GHC, please
update the test so that GHC doesn't regress again)
    Expected    T13056(optasm) bytes allocated: 440548592 +/-5%
    Lower bound T13056(optasm) bytes allocated: 418521162 
    Upper bound T13056(optasm) bytes allocated: 462576022 
    Actual      T13056(optasm) bytes allocated: 417666128 
    Deviation   T13056(optasm) bytes allocated:      -5.2 %
*** unexpected stat test failure for T13056(optasm)

Probably some creep, given how close it is to cut-off percentage.
According to 
https://perf.haskell.org/ghc/#graph/tests/alloc/T13056
this has been stable in the last 50 commits
(sorry, still no way to view these graph for any other time interval).

> ·         If compile times went up, would that show up anywhere
> (except in testsuite results)?

Only if it changes the total time of running make, or if it affects the
allocations of a compiler perf test case.

We currently have no reliable compilation time benchmarks (which would
require _compiling_ stuff NofibRun times).

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.dehttps://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170413/9470612b/attachment.sig>


More information about the ghc-devs mailing list