<div class="gmail_quote">On Sun, Jul 10, 2011 at 13:36, John Chludzinski <span dir="ltr"><<a href="mailto:jchludzinski@gmail.com">jchludzinski@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>I assume you mean: neither pthreads nor MPI "offers very little potential performance improvement on a system like this"?</div></blockquote><div><br></div><div>No, you can get a decent parallel speedup with smaller systems or "thin" nodes. It should be at least as much as the increase in memory bandwidth, and can be better if your workload has enough floating point operations.</div>
<div><br></div><div>My claim was that the difference between all-MPI and hybrid MPI/pthreads will not be large on this sort of hardware. So you don't suffer from just using MPI everywhere. If the heavy computation is well-isolated to either a library or a localized bit of code, then it's not difficult to add threading later (e.g. when you switch hardware).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><br></div><div>I work for a small company (in Huntsville) of mechanical engineers with a limited budget where such machines are their staple. I'm looking at PETSc and SLEPc to help with some of their large scale problems (e.g., generalized eigenvalue problems for matrices from 10K x 10K to matrices over 100K x 100K).<br>
</div></blockquote><div><br></div><div>This problem size is not very large.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div></div><div>I'm also looking at ways to parallelize of own codes, hence pthreads vs. MPI?</div>
</blockquote></div><div><br></div><div>MPI forces you to think about data locality up-front, which almost always produces better software, even if you end up also using threads.</div>