Chris, There are a few things here.
- 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. - 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. - 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 https://www.amazon.co.uk/gp/product/1420082795/ref=pd_bxgy_14_img_2?ie=UTF8&psc=1&refRID=P08F0WS4W6Q6Q6K8CSCF) and I have some vague plans for what direction to take. - 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? Cheers Simon On 17 October 2016 at 18:08, Christopher Allen <[email protected]> wrote: > It'd be unfortunate if more companies trying out Haskell came to the > same result: https://blog.pusher.com/latency-working-set-ghc-gc- > pick-two/#comment-2866985345 > (They gave up and rewrote the service in Golang) > > Most of the state of the art I'm aware of (such as from Azul Systems) > is from when I was using a JVM language, which isn't necessarily > applicable for GHC. > > I understand Marlow's thread-local heaps experiment circa 7.2/7.4 was > abandoned because it penalized performance too much. Does the > impression that there isn't the labor to maintain two GCs still hold? > It seems like thread-local heaps would be pervasive. > > Does anyone know what could be done in GHC itself to improve this > situation? Stop-the-world is pretty painful when the otherwise > excellent concurrency primitives are much of why you're using Haskell. > > --- Chris Allen > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
