<div dir="ltr"><div class="gmail_extra"><div><div><br></div></div><div class="gmail_quote">On Thu, Oct 8, 2015 at 1:36 PM, Berk Hess <span dir="ltr"><<a href="mailto:hess@kth.se" target="_blank">hess@kth.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Interesting read. The essential message
is:<br>
"Thus, we believe that a discussion on threads versus processes
boils down to “shared everything by default” versus “shared
nothing by default”.<br>
We came to the same conclusion in a discussion some time ago. So
the choice doesn't affect performance, but it strongly affects the
code.<br></div></div></blockquote><div><br></div><div>Another important point is that "the launching of additional streams of control from a given stream of control" even if done via thread-pool has high overhead. In contrast, launching these streams of control, be it thread or processes, at the beginning of the run is a better strategy from the pov of performance. This however results in a design that's very similar to the one used with MPI - with the crucial difference that you point out above and which becomes quite problematic with such an approach and essentially all data in the MD loop would become shared with OpenMP. Clearly, I think, the huge legacy code-base is in the way and default private data would, from this point of view, be more beneficial, it seems.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
For Gromacs I think it's still convenient to have
processes+threads, since we have many data structures with many
small arrays that change at domain decomposition time that are
needed by all threads in a domain. Sharing all these through MPI3
is tedious.<br></div></div></blockquote><div><br></div><div>Agreed. It would required quite some code reorganization. However, starting N worker threads outside the MD loop and keeping them alive (with all data shared) does not seem less tedious either.</div><div><br></div><div>--</div><div>Szilárd<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
<br>
Cheers,<br>
<br>
Berk<div><div><br>
<br>
On 10/08/2015 01:04 PM, Szilárd Páll wrote:<br>
</div></div></div><div><div>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>"We believe that portions of the HPC community have adopted
the point of view that somehow threads are “necessary” in
order to utilize such [manycore/SMP] systems, (1) without
fully understanding the alternatives, including MPI 3
functionality, (2) underestimating the difficulty of utilizing
threads efficiently, and (3) without appreciating the
similarities of threads and processes. This short paper, due
to space constraints, focuses exclusively on issue (3) since
we feel it has gotten virtually no attention."<br>
</div>
<div><br>
</div>
<a href="http://www.orau.gov/hpcor2015/whitepapers/Exascale_Computing_without_Threads-Barry_Smith.pdf" target="_blank">http://www.orau.gov/hpcor2015/whitepapers/Exascale_Computing_without_Threads-Barry_Smith.pdf</a><br clear="all">
<div><br clear="all">
<div>
<div>--<br>
Szilárd</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</blockquote>
<br>
</div></div></div>
<br>--<br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br></blockquote></div><br></div></div>