Re: Residency profiles

[Sebastian Graf]

This recently came up again. It seems that `+RTS -h -i0` will just turn
every minor collection into a major one:
https://gitlab.haskell.org/ghc/ghc/issues/17387#note_248705
`-i0` seems significantly different from `-i0.001`, say, in that it just
turns minor GCs into major ones and doesn't introduce non-determinism
otherwise. Sampling rate can be controlled with `-A`, much like `-F1` (but
it's still faster for some reason).

Am Mo., 10. Dez. 2018 um 09:11 Uhr schrieb Simon Marlow :

> https://phabricator.haskell.org/D5428
>
>
> On Sun, 9 Dec 2018 at 10:12, Sebastian Graf  wrote:
>
>> Ah, I was only looking at `+RTS --help`, not the users guide. Silly me.
>>
>> Am Do., 6. Dez. 2018 um 20:53 Uhr schrieb Simon Marlow <
>> marlo...@gmail.com>:
>>
>>> It is documented!
>>> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/runtime_control.html#rts-flag--F%20%E2%9F%A8factor%E2%9F%A9
>>>
>>> On Thu, 6 Dec 2018 at 16:21, Sebastian Graf  wrote:
>>>
 Hey,

 thanks, all! Measuring with `-A1M -F1` delivers much more reliable
 residency numbers.
 `-F` doesn't seem to be documented. From reading `rts/RtsFlags.c` and
 `rts/sm/GC.c` I gather that it's the factor by which to multiply the number
 of live bytes by to get the new old gen size?
 So effectively, the old gen will 'overflow' on every minor GC, neat!

 Greetings
 Sebastian

 Am Do., 6. Dez. 2018 um 12:52 Uhr schrieb Simon Peyton Jones via
 ghc-devs :

> |  Right. A parameter for fixing the nursery size would be easy to
> implement,
> |  I think. Just a new flag, then in GC.c:resize_nursery() use the
> flag as the
> |  nursery size.
>
> Super!  That would be v useful.
>
> |  "Max. residency" is really hard to measure (need to do very
> frequent GCs),
> |  perhaps a better question to ask is "residency when the program is
> in state
> |  S".
>
> Actually, Sebastian simply wants to see an accurate, reproducible
> residency profile, and doing frequent GCs might well be an acceptable
> cost.
>
> Simon
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Bug in SRT generation for procs in .cmm files?

[Ömer Sinan Ağacan]

The main problem I'm trying to solve is explained in my comment [1]. Basically
when building .cmm files the new SRT algorithm re-order definitions in a way
that breaks dependency ordering, which in turn breaks C backend, because in C we
should declare before using. (see my comment for why we don't have this problem
when building Haskell modules)

If we don't allow defining CAFFY things in Cmm files then I can simply not do
SRT analysis on Cmm files and avoid the problem.

Ömer

[1]: https://gitlab.haskell.org/ghc/ghc/merge_requests/1304#note_248547

Ben Gamari , 23 Oca 2020 Per, 15:17 tarihinde şunu yazdı:
>
> While it's true that in principle one could imagine a case where you would 
> want a CAFfy Cmm proc, I can't think of any stuck cases in the RTS today. 
> Consequently it wouldn't surprise me if this was broken.
>
> Frankly, I wouldn't worry too much about this if it's nontrivial to fix.
>
> Cheers,
>
> - Ben
>
> On January 23, 2020 1:54:04 AM EST, "Ömer Sinan Ağacan" 
>  wrote:
>>
>> 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
>> 
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: GHC perf

[Simon Peyton Jones via ghc-devs]

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 
Sent: 23 January 2020 14:48
To: Simon Peyton Jones 
Subject: Re: GHC perf

Which wiki page?
https://gitlab.haskell.org/ghc/ghc/wikis/building/running-tests/performance-tests
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.
 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



Registered in England & Wales, OC335890

118 Wymering Mansions, Wymering Road, London W9 2NF, England
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How to turn LHExpr GhcPs into CoreExpr

[Shao, Cheng]

How about using `hscCompileCoreExprHook` to intercept the `CoreExpr`
from the ghci pipeline? There exist GHC API to evaluate a String to a
ForeignHValue iirc; we are not interested in the final ForeignHValue
in this case, we just want the CoreExpr, and the logic of generating
and linking BCO can be discarded.

Cheers,
Cheng

On Thu, Jan 23, 2020 at 1:55 PM Ben Gamari  wrote:
>
> It is slightly disheartening that this relatively simple use-case requires 
> reaching so deeply into the typechecker.
>
> If there really exusts no easier interface then perhaps we should consider 
> adopting your elaborateExpr as part of the GHC API.
>
> Cheers,
>
> - Ben
>
> On January 23, 2020 4:04:03 AM EST, Richard Eisenberg  
> wrote:
>>
>> I don't know the exact semantics of the interactive context, etc., but that 
>> looks plausible. It won't give the *wrong* answer. :)
>>
>> Thanks for sharing!
>> Richard
>>
>> On Jan 23, 2020, at 4:52 AM, Yiyun Liu  wrote:
>>
>> Thank you all for your help! It turns out that I was missing the constraint 
>> solving and zonking step by desugaring the result of tcInferSigma directly.
>>
>> I have the implementation of the function here. Not sure if it's 100% 
>> correct but at least it works for all the examples I can come up with so far.
>>
>> - Yiyun
>>
>> On 1/22/20 7:09 AM, Andreas Klebinger wrote:
>>
>> I tried this for fun a while ago and ran into the issue of needing to 
>> provide a type environment containing Prelude and so on.
>> I gave up on that when some of the calls failed because I must have missed 
>> to set up some implicit state properly.
>> I didn't have an actual use case (only curiosity) so I didn't look further 
>> into it. If you do find a way please let me know.
>>
>> I would also support adding any missing functions to GHC-the-library to make 
>> this possible if any turn out to be required.
>>
>> As an alternative you could also use the GHCi approach of using a fake 
>> Module. This would allow you to copy whatever GHCi is doing.
>> But I expect that to be slower if you expect to process many such strings,
>>
>> Richard Eisenberg schrieb am 22.01.2020 um 10:36:
>>
>> You'll need to run the expression through the whole pipeline.
>>
>> 1. Parsing
>> 2. Renaming
>> 3. Type-checking
>>   3a. Constraint generation
>>   3b. Constraint solving
>>   3c. Zonking
>> 4. Desugaring
>>
>>
>>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How to turn LHExpr GhcPs into CoreExpr

[Ben Gamari]

It is slightly disheartening that this relatively simple use-case requires 
reaching so deeply into the typechecker.

If there really exusts no easier interface then perhaps we should consider 
adopting your elaborateExpr as part of the GHC API.

Cheers, 

- Ben 

On January 23, 2020 4:04:03 AM EST, Richard Eisenberg  wrote:
>I don't know the exact semantics of the interactive context, etc., but
>that looks plausible. It won't give the *wrong* answer. :)
>
>Thanks for sharing!
>Richard
>
>> On Jan 23, 2020, at 4:52 AM, Yiyun Liu 
>wrote:
>> 
>> Thank you all for your help! It turns out that I was missing the
>constraint solving and zonking step by desugaring the result of
>tcInferSigma directly.
>> I have the implementation of the function here
>.
>Not sure if it's 100% correct but at least it works for all the
>examples I can come up with so far.
>> - Yiyun
>> On 1/22/20 7:09 AM, Andreas Klebinger wrote:
>>> I tried this for fun a while ago and ran into the issue of needing
>to provide a type environment containing Prelude and so on.
>>> I gave up on that when some of the calls failed because I must have
>missed to set up some implicit state properly.
>>> I didn't have an actual use case (only curiosity) so I didn't look
>further into it. If you do find a way please let me know.
>>> 
>>> I would also support adding any missing functions to GHC-the-library
>to make this possible if any turn out to be required.
>>> 
>>> As an alternative you could also use the GHCi approach of using a
>fake Module. This would allow you to copy whatever GHCi is doing.
>>> But I expect that to be slower if you expect to process many such
>strings, 
>>> 
>>> Richard Eisenberg schrieb am 22.01.2020 um 10:36:
 You'll need to run the expression through the whole pipeline.
 
 1. Parsing
 2. Renaming
 3. Type-checking
   3a. Constraint generation
   3b. Constraint solving
   3c. Zonking
 4. Desugaring
>>> 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: GHC perf

[Simon Peyton Jones via ghc-devs]

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 
Sent: 23 January 2020 11:19
To: Simon Peyton Jones 
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,  and  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  commit.
  2.  Use `git status` to double check git sees a clean working tree.
  3.  Run the performance tests.
  4.  Check out your  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  
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 "" 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 
Sent: 20 January 2020 10:37
To: Simon Peyton Jones ; 
Ben Gamari 
Cc: ghc-devs 
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).

  *   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  commit.
  2.  Use `git status` to double check git sees a clean working tree.
  3.  Run the performance tests.
  4.  Check out your  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  
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. 
Ide

Re: Bug in SRT generation for procs in .cmm files?

[Ben Gamari]

While it's true that in principle one could imagine a case where you would want 
a CAFfy Cmm proc, I can't think of any stuck cases in the RTS today.  
Consequently it wouldn't surprise me if this was broken.

Frankly, I wouldn't worry too much about this if it's nontrivial to fix. 

Cheers, 

 - Ben 

On January 23, 2020 1:54:04 AM EST, "Ömer Sinan Ağacan"  
wrote:
>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
>___
>ghc-devs mailing list
>ghc-devs@haskell.org
>http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How to turn LHExpr GhcPs into CoreExpr

[Richard Eisenberg]

I don't know the exact semantics of the interactive context, etc., but that 
looks plausible. It won't give the *wrong* answer. :)

Thanks for sharing!
Richard

> On Jan 23, 2020, at 4:52 AM, Yiyun Liu  wrote:
> 
> Thank you all for your help! It turns out that I was missing the constraint 
> solving and zonking step by desugaring the result of tcInferSigma directly.
> I have the implementation of the function here 
> .
>  Not sure if it's 100% correct but at least it works for all the examples I 
> can come up with so far.
> - Yiyun
> On 1/22/20 7:09 AM, Andreas Klebinger wrote:
>> I tried this for fun a while ago and ran into the issue of needing to 
>> provide a type environment containing Prelude and so on.
>> I gave up on that when some of the calls failed because I must have missed 
>> to set up some implicit state properly.
>> I didn't have an actual use case (only curiosity) so I didn't look further 
>> into it. If you do find a way please let me know.
>> 
>> I would also support adding any missing functions to GHC-the-library to make 
>> this possible if any turn out to be required.
>> 
>> As an alternative you could also use the GHCi approach of using a fake 
>> Module. This would allow you to copy whatever GHCi is doing.
>> But I expect that to be slower if you expect to process many such strings, 
>> 
>> Richard Eisenberg schrieb am 22.01.2020 um 10:36:
>>> You'll need to run the expression through the whole pipeline.
>>> 
>>> 1. Parsing
>>> 2. Renaming
>>> 3. Type-checking
>>>   3a. Constraint generation
>>>   3b. Constraint solving
>>>   3c. Zonking
>>> 4. Desugaring
>> 

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs