On Thu, Nov 24, 2011 at 2:30 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div class="im">On Thu, Nov 24, 2011 at 14:17, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>    Come on, stop being silly; it has nothing to do with the fact that it is MPI+something.  It is because it is too complicated and hard to use and both MPI and pthreads have bad limitations (for pthreads it is the fact that pthreads does not have a good way of waking up many pthreads together to do something, for MPI it is due to point to point and one sided do not allow proper scheduling of communication at the low level).<br>

</div></blockquote><div><br></div></div><div>This is why they added neighborhood collectives.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>

<div><br>
> What about a library that was implemented in terms of MPI and pthreads, but gave you a more consistent abstraction?<br>
<br>
</div>   That would be fine, even great. I just don't believe that either of them are the right base to build on.<br></div></blockquote><div><br></div></div><div>I think of MPI as an abstraction for the network and pthreads as an abstraction for kernel management of threads. If you don't want to build on them, we need to justify why they are bad abstractions (and have different network or kernel-level implementations). The abstraction being good has nothing to do with whether it has a nice API for users, it's whether it provides a suitable model for the lower level (network hardware or kernel) upon which useful abstractions can be written.</div>
</div></blockquote><div><br></div><div>We need abstractions for both execution and data access. MPI has independent processes with barriers, and completely independent</div><div>memory augmented with messages. This is a pretty good model, however we have the "halo problem" with high core counts (as well as</div>
<div>a simple lack of memory/core). Threads is one solution to this. In my opinion, it is completely crap on all counts. An alternative model,</div><div>from the Cray, is vector processing. CUDA is basically a combination of MPI and Vectors (everything else is incidental). I believe that this</div>
<div>can work since it is eminently programmable and debuggable.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
   You sound a bit like Jack telling me in 1994 that I should write PETSc on top of Scalapack.</div></blockquote></div></div><br><div>Or maybe like Bill suggesting that you use C and make it run on operating systems that exist? ;-)</div>

</blockquote></div><br>So Seymour Cray is telling you guys not to fuck this up.<div><br></div><div>    Matt<br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener<br>
</div>