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

[Simon Peyton Jones]

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 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
| 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.de • https://www.joachim-breitner.de/
|   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
|   Debian Developer: nomeata at debian.org