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:[email protected]] | Sent: 13 April 2017 16:24 | To: Simon Peyton Jones <[email protected]> | Cc: ghc-devs <[email protected]> | 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 | [email protected] • https://www.joachim-breitner.de/ | XMPP: [email protected] • OpenPGP-Key: 0xF0FBF51F | Debian Developer: [email protected] _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
