<div>I think the problem becomes slightly easier if you can provide an upper bound on the time GC will take. If I understand your problem domain, Neil, you&#39;re most concerned with holding up other processes/partitions who are expecting to have a certain amount of processing time per frame. If we can give an upper bound to the GC time, then we can plan for it in the schedule without upsetting the other processes.</div>

<div> </div>
<div>I don&#39;t have an answer (though I&#39;d love one), but I do think that asking for an upper bound substantially simplifies the problem (though, I could be wrong) and still gives you the characterisics you need to give a &#39;time to complete&#39;.<br>
</div>
<div>/jve<br></div>
<div class="gmail_quote">On Fri, May 1, 2009 at 4:14 AM, Neil Davies <span dir="ltr">&lt;<a href="mailto:semanticphilosopher@googlemail.com">semanticphilosopher@googlemail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi<br><br>With the discussion on threads and priority, and given that (in Stats.c) there are lots of useful pieces of information that the run time system is collecting, some of which is already visible (like the total amount of memory mutated) and it is easy to make other measures available - it has raised this question in my mind:<br>
<br>Given that you have access to that information (the stuff that comes out at the end of a run if you use +RTS -S) is it possible to estimate the time a GC will take before asking for one?<br><br>Ignoring, at least for the moment, all the issues of paging, processor cache occupancy etc, what are the complexity drivers for the time to GC?<br>
<br>I realise that it is going to depend on things like, volume of data mutated, count of objects mutated, what fraction of them are live etc - and even if it turns out that these things are very program specific then I have a follow-on question - what properties do you need from your program to be able to construct a viable estimate of GC time from a past history of such garbage collections?<br>
<br>Why am I interested? There are all manners of &#39;real time&#39; in systems, there is a vast class where a statistical bound (ie some sort of &#39;time to complete&#39; CDF) is more than adequate for production use. If this is possible then it opens up areas where all the lovely properties of haskell can be exploited if only you had confidence in the timing behaviour.<br>
<br>Cheers<br>Neil<br>_______________________________________________<br>Haskell-Cafe mailing list<br><a href="mailto:Haskell-Cafe@haskell.org" target="_blank">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>
</blockquote></div><br><br clear="all">
<div></div><br>-- <br>/jve<br>