[Diffusion] [Raised Concern] rGHC751996e90a96: Kill off complications in CoreFVs
Simon Peyton Jones
simonpj at microsoft.com
Tue Apr 18 22:49:13 UTC 2017
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?
| -----Original Message-----
| From: Joachim Breitner [mailto:mail at joachim-breitner.de]
| Sent: 13 April 2017 16:24
| To: Simon Peyton Jones <simonpj at microsoft.com>
| Cc: ghc-devs <ghc-devs at haskell.org>
| 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
| 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
| * 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
| 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
| 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).
| Joachim “nomeata” Breitner
| mail at joachim-breitner.de • https://www.joachim-breitner.de/
| XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
| Debian Developer: nomeata at debian.org
More information about the ghc-devs