[gmx-developers] interesting read: exascale w/o threads

[Szilárd Páll]

On Thu, Oct 8, 2015 at 1:36 PM, Berk Hess <hess at kth.se> wrote:

> Interesting read. The essential message is:
> "Thus, we believe that a discussion on threads versus processes boils down
> to “shared everything by default” versus “shared nothing by default”.
> 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.
>

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.


> 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.
>

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.

--
Szilárd


>
> Cheers,
>
> Berk
>
>
> On 10/08/2015 01:04 PM, Szilárd Páll wrote:
>
>
> "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."
>
>
> http://www.orau.gov/hpcor2015/whitepapers/Exascale_Computing_without_Threads-Barry_Smith.pdf
>
> --
> Szilárd
>
>
>
>
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20151008/249e208a/attachment.html>