January 2020 - ghc-devs

[ghc-steering-committee] The GHC Committee welcomes its new members
by Joachim Breitner 24 Jan '20

24 Jan '20

Dear Haskell community, the GHC Steering committee welcomes three new members, Alejandro Serrano Mena, Cale Gibbard and Tom Harding. We are happy to see that there is continued interest in our work, and are looking forward to having fresh insights and energy on the committee. They take the seat of Sandy Maguire, who we thank for this productive work during his tenure. As you might notice, we picked more candidates than we filled slots. This is not because Sandy’s productivity need three people to fill. The idea is that there is no reason to turn away a motivated contributor just to stick to the arbitrary 10 members. Instead, we will aim at “roughly 10”, and probably not call for new members until we have dropped below that number again. On behalf of the committee, Joachim Breitner PS: Alejandro, Cale and Tom, please send me your github handles and subscribe to the mailing list at https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de https://www.joachim-breitner.de/

1 0

Bug in SRT generation for procs in .cmm files?
by Ömer Sinan Ağacan 24 Jan '20

24 Jan '20

Hi Simon, Currently CmmParse only generates CmmLabels for procs, and those are considered non-CAFFY by hasCAF (and thus CmmBuildInfoTables). As a result if I have two procs in a .cmm file: - p1, refers to a CAF in base - p2, refers to p1 I *think* (haven't checked) we don't consider p1 as CAFFY, and even if we do, we don't consider p2 as CAFFY becuase the reference from p2 to p1 won't be considered CAFFY by hasCAF. So we currently can't define a CAFFY Cmm proc in .cmm files as the SRT algorithm will never build SRTs for procs in .cmm files. Is this intentional? I'd expect this to be possible, because there's nothing preventing me from referring to a CAFFY definition in a library (e.g. base) in a .cmm file, but doing this would be a bug in runtime. Thanks, Ömer

3 3

Residency profiles
by Simon Peyton Jones 23 Jan '20

23 Jan '20

Simon, Ben, Omer As you'll see in comments 55-72 of https://ghc.haskell.org/trac/ghc/ticket/9476, Sebastian has been a bit flummoxed by the task of measure residency profiles; that is, how much data is truly live during execution. A major GC measures that, but we are vulnerable to exactly when it happens (even with -G1) and that can lead to irreproducible results. I think what we want is a way to trigger GC at very regular intervals, after (say) each 10kbytes or 100kbytes or 1Mbyte of allocation. That might be expensive, but we'd get reproducible results. I don't think that is possible right now - see the ticket - but it would be easy enough to do wouldn't it? Just give only 10k or 100k or 1M to the allocator when setting it running again. Would you consider this? Or are we just missing something obvious? Needless to say, we want to do all this with full optimisation on, no cost-centre profiling. Thanks Simon

4 8

RE: GHC perf
by Simon Peyton Jones 23 Jan '20

23 Jan '20

We store the metrics in git notes *per-commit*. All metrics for commit XX are stored on the git note for commit XX. You can even view the raw data with this command (where XX is the commit hash): OK. But the master repo *already* has perf notes for that commit (I assume). Do mine somehow overwrite the master copy? So suppose, on my local machine, I do $ git checkout a12b34c56 && git submodule update --init $ ./hadrian/build.sh test --only-perf Now you say that I'm going to create git notes for a12b34c56. But those are purely for my local machine! Maybe my compiler is build with -DDEBUG. I don't want them to accidentally land in the main repo as the canonical perf figures for a12b34c56. How do I avoid accidentally pushing them? I should stress one caveat: we do not save metrics if you have uncommitted changes. Oh wow. Put that in MASSIVE BOLD CAPITALS. You mean that the entire exercise will (silently) be bogus if I have any uncommitted changes? That's a bit of a pain if I make a change, run some perf tests, make another change, run again. But I can live with it if I know. Simon From: David Eichmann <davide(a)well-typed.com> Sent: 23 January 2020 14:48 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: GHC perf Which wiki page? https://gitlab.haskell.org/ghc/ghc/wikis/building/running-tests/performance…<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> Ah. Now I'm lost. Somehow the second and fourth line must be recording info, locally in my tree, but two distinct batches of information. Perhaps kept distinct by the current commit? Where is the info actually stored? All metric results are stored in git notes. This is a feature of git that lets you attach arbitrary text to a commit (without affecting the commit's hash). It's mentioned here<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…>. Whenever you run a performance test, the raw metrics will be appended to the git note for the current commit in a simple tab separated value (tsv) format. OK, suppose I start from commit XX, and make some local changes. Then I do the -only-perf thing. presumably that'll be recorded tagged with XX. That's fine; just want it to be clear. Worth adding this info to the wiki page, so we have a clear mental model. We store the metrics in git notes *per-commit*. All metrics for commit XX are stored on the git note for commit XX. You can even view the raw data with this command (where XX is the commit hash): $ git notes --ref perf show XX NOTE `--only-perf` is optional. It limits the test runner to only run performance tests but the performance metrics will be stored regardless of this option. So, if you've ever run performance test locally, chances are the metrics will have be record without you even knowing. I should stress one caveat: we do not save metrics if you have uncommitted changes. -- David Eichmann, Haskell Consultant Well-Typed LLP, http://www.well-typed.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well-t…> Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England

1 0

How to turn LHExpr GhcPs into CoreExpr
by Yiyun Liu 23 Jan '20

23 Jan '20

Hi ghc-devs, I've been trying to implementing a function with the signature: elaborateExpr :: GhcMonad m => String -> m CoreExpr It should take a string of the form: "\x y -> x <> y :: Semigroup a => a -> a -> a" and give back a core expression with the dictionaries filled in: \ ($dSem :: Semigroup a) (x :: a) (y :: a) -> (<>) $dSem x y The goal is to use the function to add elaboration support for liquidhaskell. I looked into the implementation of exprType <https://hackage.haskell.org/package/ghc-8.6.5/docs/CoreUtils.html#v:exprType> and defined my own elaborateExpr <https://github.com/yiyunliu/ghc-elaboration-test/blob/30b3307469df15789cf1a…> similarly by calling desugarExpr <https://hackage.haskell.org/package/ghc-8.6.5/docs/Desugar.html#v:deSugarEx…> on the expression (which has type LHsExpr GhcTcId) returned by tcInferSigma. GhcTcId is a synonym of GhcTc so the program I wrote typechecks, but it's definitely not right. The elaborateExpr function I defined would return something even when the expression doesn't typecheck, or occasionally give a runtime exception: ghc-elaboration-test: panic! (the 'impossible' happened) (GHC version 8.6.5 for x86_64-unknown-linux): dsEvBinds I must have broken some invariants somehow. What is the correct way of defining such a function (takes a string and returns a CoreExpr)? It appears to me that I should convert LHsExpr GhcPs into LHsExpr GhcTc first before calling deSugarExpr, but I don't know how. Thank you, - Yiyun

5 6

RE: GHC perf
by Simon Peyton Jones 23 Jan '20

23 Jan '20

Thanks This information is a bit spread out over the wiki page. Which wiki page? Yes, it'd be fantastic to write this out clearly. Thanks! $ git checkout a12b34c56 && git submodule update --init $ ./hadrian/build.sh test --only-perf $ git checkout x98y76z54 && git submodule update --init $ ./hadrian/build.sh test --only-perf $ python3 testsuite/driver/perf_notes.py --chart chart.html --test-env local a12b34c56 x98y76z54 $ firefox chart.html Ah. Now I'm lost. Somehow the second and fourth line must be recording info, locally in my tree, but two distinct batches of information. Perhaps kept distinct by the current commit? Where is the info actually stored? OK, suppose I start from commit XX, and make some local changes. Then I do the -only-perf thing. presumably that'll be recorded tagged with XX. That's fine; just want it to be clear. Worth adding this info to the wiki page, so we have a clear mental model. Thanks Simon From: David Eichmann <davide(a)well-typed.com> Sent: 23 January 2020 11:19 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: GHC perf Simon * This compares two local builds Yes * It does not require fetching CI perf data; in fact it 100% independent of the CI system Yes * It does require two separate build trees (that is fine) No, this does not require different build trees, <baseline> and <target> are git commits (or similar e.g. branch name). The actual process might look like: $ git checkout a12b34c56 && git submodule update --init $ ./hadrian/build.sh test --only-perf $ git checkout x98y76z54 && git submodule update --init $ ./hadrian/build.sh test --only-perf $ python3 testsuite/driver/perf_notes.py --chart chart.html --test-env local a12b34c56 x98y76z54 $ firefox chart.html This information is a bit spread out over the wiki page. Perhaps a "quick start" section describing this use case would be helpful. On 1/22/20 10:54 AM, Simon Peyton Jones wrote: David Thanks. Concerning this: 1. Checkout an the <baseline> commit. 2. Use `git status` to double check git sees a clean working tree. 3. Run the performance tests. 4. Check out your <target> branch. 5. Use `git status` to double check git sees a clean working tree (else commit any changes) 6. Run the performance tests. 7. Compare metrics (filtering for `local` metrics and outputting a chart): python3 testsuite/driver/perf_notes.py --chart chart.html --test-env local <baseline> <target> I believe that * This compares two local builds * It does not require fetching CI perf data; in fact it 100% independent of the CI system * It does require two separate build trees (that is fine) Is that right? If so, two questions * In that Python command line (step 7) is "<baseline>" the path to the root of the baseline tree, or to some file within that tree? * Is this process (and what it does) written up on some wiki page somewhere? Where? Rather than replying to me individually, it'd be better to use this conversation to produce better guidance for everyone. Thanks Simon From: David Eichmann <davide(a)well-typed.com><mailto:davide@well-typed.com> Sent: 20 January 2020 10:37 To: Simon Peyton Jones <simonpj(a)microsoft.com><mailto:simonpj@microsoft.com>; Ben Gamari <ben(a)well-typed.com><mailto:ben@well-typed.com> Cc: ghc-devs <ghc-devs(a)haskell.org><mailto:ghc-devs@haskell.org> Subject: Re: GHC perf Hi Simon, * There are two things going on: * CI perf measurements * Local machine perf measurements I think that they are somehow handled differently (why?) but they are all muddled up on the wiki page. They are handled differently because we do not want to compare local metrics with CI metrics. The exception is when local metrics don't exist, then we fall back to CI metrics as a baseline (see How baseline metrics are calculated<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…>). * My goal is this: * Start with a master commit, say from Dec 2019. * Implement some change, on a branch. * sh validate -legacy (or something else if you like) * Look at perf regressions. Getting to the *raw data* should be easy: 1. Checkout an the <baseline> commit. 2. Use `git status` to double check git sees a clean working tree. 3. Run the performance tests. 4. Check out your <target> branch. 5. Use `git status` to double check git sees a clean working tree (else commit any changes) 6. Run the performance tests. 7. Compare metrics (filtering for `local` metrics and outputting a chart): python3 testsuite/driver/perf_notes.py --chart chart.html --test-env local <baseline> <target> see `python3 testsuite/driver/perf_notes.py --help` for more filtering options. This doesn't detect regressions automatically, it only shows you the raw data. Ideally we'd add an option to the testrunner to let you specify a baseline commit manually. I suspect that would be close to what you're looking for. * I believe I have first to utter the incantation $ git fetch https://gitlab.haskell.org/ghc/ghc-performance-notes.git<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> refs/notes/perf:refs/notes/ci/perf Yes, this fetches the latest CI metrics into your git notes. * But then: * How do I ensure that the baseline perf numbers I get relate to the master commit I started from, back in Dec 2019? I don't want numbers from Jan 2020. see above. * If I rebase my branch on top of HEAD, say, how do I update the perf baseline numbers to be for HEAD The test runner should use HEAD's metrics automatically (see How baseline metrics are calculated<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…>), though you will need to fetch CI metrics or run the perf tests locally on HEAD to get the relevant metrics. * Generally, how can I tell the commit to which the baseline numbers relate? The test runner will output (per test) which baseline commit is used e.g. "... from local baseline @ HEAD~2" says the baseline was a local run from 2 commits ago. * Also, in my tree I have a series of incremental changes; I want to see if any of them have perf regressions. How do I do that? You can run the perf tests on each commit *in commit order*, and the previous commit will always be used as the baseline. You can also then chart the results: python3 testsuite/driver/perf_notes.py --chart chart.html --test-env local <oldestCommit>..<newestCommit> Sorry if this is a bit unoptimal, but I Hope that helps - David E -- David Eichmann, Haskell Consultant Well-Typed LLP, http://www.well-typed.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well-t…> Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England -- David Eichmann, Haskell Consultant Well-Typed LLP, http://www.well-typed.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well-t…> Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England

1 0

FloatRep and DoubleRep ADT Argument in STG
by Csaba Hruska 22 Jan '20

22 Jan '20

Hello, I try to use GHC backend via STG. For that reason I build small STG program AST maually. So far the generated programs worked fine (compile/link/run). However I run into problems when a lifted ADT has a FloatRep argument. Interestingly it works for DoubleRep. I'm using GHC 8.6.1 64 bit to generate the code for the constructed STG AST. I wonder if I break an invariant or is this actually a bug? Is it valid to use FloatRep argument in a boxed ADT on 64 bit? I made a gist with the Haskell source and the generated Cmm code is also included. https://gist.github.com/csabahruska/e9e143390c863f7b10b0298a7ae80ac1 Working program (DoubleRep): https://gist.github.com/csabahruska/e9e143390c863f7b10b0298a7ae80ac1#file-s… Wrong program (FloatRep): https://gist.github.com/csabahruska/e9e143390c863f7b10b0298a7ae80ac1#file-s… Thanks, Csaba

2 5

GHC perf
by Simon Peyton Jones 22 Jan '20

22 Jan '20

Ben, David I'm still baffled by how to reliably get GHC perf metrics on my local machine. The wiki page https://gitlab.haskell.org/ghc/ghc/wikis/building/running-tests/performance… helps, but not enough! * There are two things going on: * CI perf measurements * Local machine perf measurements I think that they are somehow handled differently (why?) but they are all muddled up on the wiki page. * My goal is this: * Start with a master commit, say from Dec 2019. * Implement some change, on a branch. * sh validate -legacy (or something else if you like) * Look at perf regressions. * I believe I have first to utter the incantation $ git fetch https://gitlab.haskell.org/ghc/ghc-performance-notes.git refs/notes/perf:refs/notes/ci/perf * But then: * How do I ensure that the baseline perf numbers I get relate to the master commit I started from, back in Dec 2019? I don't want numbers from Jan 2020. * If I rebase my branch on top of HEAD, say, how do I update the perf baseline numbers to be for HEAD? * Generally, how can I tell the commit to which the baseline numbers relate? * Also, in my tree I have a series of incremental changes; I want to see if any of them have perf regressions. How do I do that? Thanks Simon

2 2

Marge bot review link
by lonetiger＠gmail.com 22 Jan '20

22 Jan '20

Hi Ben, I’m wondering if it’s possible to get marge to amend the commit message before it merges it to include links to the review requests. I really miss that phab feature.. Thanks, Tamar

4 3

Using lzip instead of xz for distributed tarballs
by Vanessa McHale 21 Jan '20

21 Jan '20

Hello all, GHC is distributed as .tar.xz tarballs; I assume this is because it produces small tarballs. However, xz is ill-suited for archiving due to its lack of error recovery. Moreover, lzip produces smaller tarballs with GHC (I tested with ghc-8.8.2-x86_64-deb9-linux.tar) and decompression takes about the same amount of time. There's more information on the project page: https://www.nongnu.org/lzip/lzip.html. Cheers, Vanessa McHale

3 3