<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, 6 Dec 2018 at 11:15, Ömer Sinan Ağacan <<a href="mailto:omer@well-typed.com">omer@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
 > I think what we want is a way to trigger GC at very regular intervals, after<br>
 > (say) each 10kbytes or 100kbytes or 1Mbyte  of allocation.  That might be<br>
 > expensive, but we’d get reproducible results.<br>
<br>
If we could fix the nursery size to 10kb that'd trigger a GC in every 10kb of<br>
allocation (you could still allocate large objects as those are not allocated in<br>
the nursery, but perhaps that's not a problem in your benchmarks). Then by<br>
setting -G1 you could turn all GCs to major GCs (because first generation is<br>
always collected). Note that because each capability has its own nursery you may<br>
want to set the nursery size to alloc_per_gc / num_of_caps if you need more than<br>
one capability.<br>
<br>
 > I don’t think that is possible right now – see the ticket – but it would be<br>
 > easy enough to do wouldn’t it?  Just give only 10k or 100k or 1M to the<br>
 > allocator when setting it running again.<br>
<br>
Right. A parameter for fixing the nursery size would be easy to implement, I<br>
think. Just a new flag, then in GC.c:resize_nursery() use the flag as the<br>
nursery size.<br></blockquote><div><br></div><div>It's possible that +RTS -A100k -F1 would do what you want. It would keep the 2-generation setup, with a fixed nursery size, and -F1 would ensure that every collection is a major one. I haven't tested this, but if it doesn't work, it should!</div><div><br></div><div>Cheers</div><div>Simon</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
"Max. residency" is really hard to measure (need to do very frequent GCs),<br>
perhaps a better question to ask is "residency when the program is in state S".<br>
This is also hard to measure if your program is threaded or have other<br>
non-determinism, but this lets you decide when to measure residency. Currently<br>
we can't tell the GC to print residency stats, but perhaps we could implement a<br>
variant of `performGC` that prints residency after the GC. So in your program<br>
you could add `performGCPrintStats` after every iteration or step etc. Not sure<br>
how useful this would be, but just an idea..<br>
<br>
On 6.12.2018 13:09, Simon Peyton Jones wrote:<br>
> Simon, Ben, Omer<br>
> <br>
> As you’ll see in comments 55-72 of <a href="https://ghc.haskell.org/trac/ghc/ticket/9476" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/9476</a>, <br>
> Sebastian has been a bit flummoxed by the task of measure residency profiles; <br>
> that is, how much data is truly live during execution.<br>
> <br>
> A major GC measures that, but we are vulnerable to exactly when it happens (even <br>
> with -G1) and that can lead to irreproducible results.<br>
> <br>
> I think what we want is a way to trigger GC at very regular intervals, after <br>
> (say) each 10kbytes or 100kbytes or 1Mbyte  of allocation.  That might be <br>
> expensive, but we’d get reproducible results.<br>
> <br>
> I don’t think that is possible right now – see the ticket – but it would be easy <br>
> enough to do wouldn’t it?  Just give only 10k or 100k or 1M to the allocator <br>
> when setting it running again.<br>
> <br>
> Would you consider this?  Or are we just missing something obvious?<br>
> <br>
> Needless to say, we want to do all this with full optimisation on, no <br>
> cost-centre profiling.<br>
> <br>
> Thanks<br>
> <br>
> Simon<br>
> <br>
<br>
-- <br>
Ömer Sinan Ağacan, Haskell Consultant<br>
Well-Typed LLP, <a href="http://www.well-typed.com" rel="noreferrer" target="_blank">http://www.well-typed.com</a><br>
<br>
Registered in England & Wales, OC335890<br>
118 Wymering Mansions, Wymering Road, London W9 2NF, England<br>
</blockquote></div></div>