<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'd really like to see some applications that are suffering here, and analyse whether it really is contention for the shared data structure, and if so, whether there's anything else we can do. Ryan, do you have anything?</blockquote>
<div><br></div><div>Only the monad-par (and new meta-par) schedulers. There, we've certainly had problems with contention on IORefs <b>AND</b> with extra GC pressure resulting from functional updates rather than in-place updates (which some of these mutable concurrent structures alleviate). However, it would be nice to know with more clarity what exactly is keeping us from having scheduler overhead more competitive with sparks, because I can't confidently say that it is only the above issues.</div>
<div><br></div><div>One contention problem we have is that we keep adding brand new pieces of functionality (like the CPU/GPU scheduling) and inevitably in the interest of fast prototyping we initially use something basic for concurrently accessed data that performs poorly. </div>
<div> Ultimately, I think the fundamental problem applications that have a single point of contention (MVar/IORef) between all or most threads. Even the best possible implementation of a single IORef or a single MVar, (for example using CAS for update than atomicModifyIORef), will still be a bottleneck on larger SMP systems.</div>
<div> From our perspective, what we really want is the ability to drop in logically <i>singular</i> shared data structures (like the concurrent bag), which are actually using TLS behind the scenes to access mostly disjoint memory addresses. That's the place where we get a big design win in terms of keeping the client code simple but also getting scalability. (Those concurrent bags in particular perform really well and are basically a complete work-stealing implementation in a box.)</div>
<div><br></div><div>Looking forward -- we've got a real medical imaging app that we've started working on; I'll let you know if there are any particular examples of data structure contention there. But for now the monad-par/meta-par schedulers are the only example I've got.</div>
<div><br></div><div>Cheers,</div><div> -Ryan</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
Such a structure would probably have to be strict and in an ST monad,<br>
to get a usable and deterministic behaviour.<br>
<br>
Any thoughts?<br>
<br>
Cheers,<br>
Milan<br>
<br>
______________________________<u></u>_________________<br>
Libraries mailing list<br></div>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a> <javascript:;><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/libraries</a><div class="im"><br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/libraries</a><br>
</div></blockquote>
<br>
</blockquote></div><br></div>