Thank you so much Alexander and Thomas.<div><br></div><div>Regards,</div><div>Kashyap<br><br><div class="gmail_quote">On Sun, Jul 29, 2012 at 11:59 PM, Thomas Schilling <span dir="ltr"><<a href="mailto:nominolo@googlemail.com" target="_blank">nominolo@googlemail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">GHC does not provide any form of real-time guarantees (and support for<br>
them is not planned).<br>
<br>
That said, it's not as bad as it sounds:<br>
<br>
- Collecting the first (young) generation is fast and you can control<br>
the size of that first generation via runtime system (RTS) options.<br>
<br>
- The older generation is collected rarely and can be collected in parallel.<br>
<br>
- You can explicitly invoke the GC via System.Mem.performGC<br>
<br>
In a multi-threaded / multi-core program collecting the first<br>
generation still requires stopping all application threads even though<br>
only one thread (CPU) will perform GC (and having other threads help<br>
out usually doesn't work out due to locality issues). This can be<br>
particularly expensive if the OS decides to deschedule an OS thread,<br>
as then the GHC RTS has to wait for the OS. You can avoid that<br>
particular problem by properly configuring the OS via (linux boot<br>
isolcpus=... and taskset(8)). The GHC team has been working on a<br>
independent *local* GC, but it's unlikely to make it into the main<br>
branch at this time. It turned out to be very difficult to implement,<br>
with not large enough gains. Building a fully-concurrent GC is<br>
(AFAICT) even harder.<br>
<br>
I don't know how long the pause times for your 500MB live heap would<br>
be. Generally, you want your heap to be about twice the size of your<br>
live data. Other than that it depends heavily on the characteristics<br>
of you heap objects. E.g., if it's mostly arrays of unboxed<br>
non-pointer data, then it'll be very quick to collect (since the GC<br>
doesn't have to do anything with the contents of these arrays). If<br>
it's mostly many small objects with pointers to other objects, GC will<br>
be very expensive and bound by the latency of your RAM. So, I suggest<br>
you run some tests with realistic heaps.<br>
<br>
Regarding keeping up, Simon Marlow is the main person working on GHC's<br>
GC (often collaborating with others) and he keeps a list of papers on<br>
his homepage: <a href="http://research.microsoft.com/en-us/people/simonmar/" target="_blank">http://research.microsoft.com/en-us/people/simonmar/</a><br>
<br>
If you have further questions about GHC's GC, you can ask them on the<br>
<a href="mailto:glasgow-haskell-users@haskell.org">glasgow-haskell-users@haskell.org</a> mailing list (but please consult the<br>
GHC user's guide section on RTS options first).<br>
<br>
HTH<br>
<div><div class="h5"><br>
On 29 July 2012 08:52, C K Kashyap <<a href="mailto:ckkashyap@gmail.com">ckkashyap@gmail.com</a>> wrote:<br>
> Hi,<br>
> I was looking at a video that talks about GC pauses. That got me curious<br>
> about the current state of GC in Haskell - say ghc 7.4.1.<br>
> Would it suffer from lengthy pauses when we talk about memory in the range<br>
> of 500M +?<br>
> What would be a good way to keep abreast with the progress on haskell GC?<br>
> Regards,<br>
> Kashyap<br>
><br>
</div></div>> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
Push the envelope. Watch it bend.<br>
</font></span></blockquote></div><br></div>