<div dir="ltr"><div><div><div>Chris,<br><br></div>There are a few things here.<br><br></div>- There are different levels of latency-sensitivity.  The system I work on at Facebook is latency sensitive and we have no problem with the GC (after we implemented a few optimisations and did some tuning).  But we're ok with pauses up to 100ms or so, and our average pause time is <50ms with 100MB live data on large multicore machines.  There's probably still scope to reduce that some more.<br><br></div>- Thread-local heaps don't fix the pause-time issue.  They reduce the pause time for a local collection but have no impact on the global collection, which is still unbounded in size.<br><div><br></div><div>- I absolutely agree we should have incremental or concurrent collection.  It's a big project though.  Most of the technology is fairly well understood (just read <a href="https://www.amazon.co.uk/gp/product/1420082795/ref=pd_bxgy_14_img_2?ie=UTF8&psc=1&refRID=P08F0WS4W6Q6Q6K8CSCF">https://www.amazon.co.uk/gp/product/1420082795/ref=pd_bxgy_14_img_2?ie=UTF8&psc=1&refRID=P08F0WS4W6Q6Q6K8CSCF</a>) and I have some vague plans for what direction to take. <br><br></div><div>- The issue is not so much maintaining multiple GCs.  We already have 3 GCs (one of which is experimental and unsupported).  The issue is more that a new kind of GC has non-local implications because it affects read- and write-barriers, and making a bad tradeoff can penalize the performance of all code.  Perhaps you're willing to give up 10% of performance to get guaranteed 10ms pause times, but can we impose that 10% on everyone?  If not, are you willing to recompile GHC and all your libraries?<br><br></div><div>Cheers<br></div><div>Simon<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 17 October 2016 at 18:08, Christopher Allen <span dir="ltr"><<a href="mailto:cma@bitemyapp.com" target="_blank">cma@bitemyapp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It'd be unfortunate if more companies trying out Haskell came to the<br>
same result: <a href="https://blog.pusher.com/latency-working-set-ghc-gc-pick-two/#comment-2866985345" rel="noreferrer" target="_blank">https://blog.pusher.com/<wbr>latency-working-set-ghc-gc-<wbr>pick-two/#comment-2866985345</a><br>
(They gave up and rewrote the service in Golang)<br>
<br>
Most of the state of the art I'm aware of (such as from Azul Systems)<br>
is from when I was using a JVM language, which isn't necessarily<br>
applicable for GHC.<br>
<br>
I understand Marlow's thread-local heaps experiment circa 7.2/7.4 was<br>
abandoned because it penalized performance too much. Does the<br>
impression that there isn't the labor to maintain two GCs still hold?<br>
It seems like thread-local heaps would be pervasive.<br>
<br>
Does anyone know what could be done in GHC itself to improve this<br>
situation? Stop-the-world is pretty painful when the otherwise<br>
excellent concurrency primitives are much of why you're using Haskell.<br>
<br>
--- Chris Allen<br>
______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div><br></div>