Thanks Joachim. But rather than giving me a person tutorial every six months, might it not be more efficient to make the web pages self explanatory? Eg by supplying a key, by signalling more clearly that only commits with significant changes are shown etc? Simon | -----Original Message----- | From: Joachim Breitner [mailto:mail@joachim-breitner.de] | Sent: 13 April 2017 16:24 | To: Simon Peyton Jones | Cc: ghc-devs | Subject: Re: [Diffusion] [Raised Concern] rGHC751996e90a96: Kill off | complications in CoreFVs | | [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@joachim-breitner.de • https://www.joachim-breitner.de/ |   XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F |   Debian Developer: nomeata@debian.org