<br><br><div class="gmail_quote">On Fri, Mar 15, 2013 at 3:31 AM, Tobias Hammer <span dir="ltr">&lt;<a href="mailto:tobias.hammer@dlr.de" target="_blank">tobias.hammer@dlr.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I see that you left the placement of (time ...) unchanged in your with-places code. You should really exclude the (place ..)-call from your measurement.<br>
It is not fair to compare a simple loop vs. the creation of two full racket instances + the loop. See my last mail for a &#39;fairer&#39; version.<br></blockquote><div>I did that to get a feel for the overheads involved  with places.  My application should be highly parallisable and right now I&#39;m just experimenting to see how best to do that, which also includes looking at the overheads in doing things different ways and experimenting on how best to reduce them.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In a real program you should recycle places to create them only once (e.g one per core) and then send them new work items via channels.<br></blockquote><div>I did in fact do that in one of my experiments setting up a for loop that used multiple places to process multiple elements of a sequence in parallel but I found that the overhead of all the place-channel-gets and place-channel-puts made it very very much slower than a regular for loop without places. So I&#39;m also trying to refine the overhead in that scenario.</div>
<div><br></div><div>I&#39;m experimenting trying to see how best to get rid of excessive overheads.  I find I learn best by making all the naive mistakes and then fixing them.</div><div><br></div><div>Cheers,</div><div>Harry Spier </div>
</div>