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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Joachim Breitner-2
[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
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

GHC - devs mailing list
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:[hidden email]]
| Sent: 13 April 2017 16:24
| To: Simon Peyton Jones <[hidden email]>
| Cc: ghc-devs <[hidden email]>
| 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
|   [hidden email]https://www.joachim-breitner.de/
|   XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
|   Debian Developer: [hidden email]
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Joachim Breitner-2
Hi,

Am Dienstag, den 18.04.2017, 22:49 +0000 schrieb Simon Peyton Jones via
ghc-devs:
> 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?


Self-explanatory web-pages would be ideal, and I tried to make it as
self-explanatory as my limited UI skills carry me. And before I add
documentation (which gets out of date and does not get read anyways),
I’d rather refine the UI.

The missing commits are already hinted at with the somewhat thick
dotted line that replaces then. Maybe it needs to be thicker, and
possibly have a tooltip to explain it. Or I should try to recreate how
GitHub visually indicates when only part of a diff is shown.

Also, I don’t mind explaining it twice a year. This way I at least
learn if people are still using the tool :-)

Greetings,
Joachim

--
Joachim “nomeata” Breitner
  [hidden email]https://www.joachim-breitner.de/
  XMPP: [hidden email] • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: [hidden email]
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (849 bytes) Download Attachment
Loading...