<div>Mark,</div>
<div>Thanks, that led me (with a bit of wandering) to e.g. <a href="http://www.cs.virginia.edu/stream/top20/Balance.html">http://www.cs.virginia.edu/stream/top20/Balance.html</a>.</div>
<div>My immediate concern is for an app that is worse than embarassingly parallel; it can&#39;t (currently) trade memory for time, and can&#39;t really use any memory or network effectively, by the list&#39;s standards. Basically I want a zillion CPUs and they can communicate by crayon on postcard. That&#39;s not practical, but my initial valuator is just GHz/$. 
</div>
<div>I care about the memory sharing and message passing efficiency issues only in that I want to smarten up my app to take advantage of other economies.</div>
<div>Peter<br><br>&nbsp;</div>
<div><span class="gmail_quote">On 3/8/07, <b class="gmail_sendername">Mark Hahn</b> &lt;<a href="mailto:hahn@mcmaster.ca">hahn@mcmaster.ca</a>&gt; wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">&gt; Great thanks. That was clear and the takeaway is that I should pay attention<br>&gt; to the number of memory channels per core (which may be less than 
1.0)<br><br>I think the takeaway is a bit more acute: if your code is cache-friendly,<br>simply pay attention to cores * clock * flops/cycle.<br><br>otherwise (ie, when your models are large), pay attention to the &quot;balance&quot;
<br>between observed memory bandwidth and peak flops.<br><br>the stream benchmark is a great way to do this, and has traditionally<br>promulgated the &quot;balance&quot; argument.&nbsp;&nbsp;here&#39;s an example:<br><br><a href="http://www.cs.virginia.edu/stream/stream_mail/2007/0001.html">
http://www.cs.virginia.edu/stream/stream_mail/2007/0001.html</a><br><br>basically, 13 GB/s for a 2x2 opteron/2.8 system (peak flops would<br>be 2*2*2*2.8=22.4, so you need 1.7 flops per byte to be happy.<br><br>I don&#39;t have a report handy for core2, but iirc, people report hitting
<br>a wall of around 9 GB/s for any dual-FSB core2 system.&nbsp;&nbsp;assuming dual-core<br>parts like the paper, peak theoretical flops is 37 GFlops, for a balance<br>of just over 4.&nbsp;&nbsp;that ratio should really be called &quot;imbalance&quot; ;)
<br>quad-core would be worse, of course.<br></blockquote></div><br>


!DSPAM:45f06399316572020149523!