<br><br><div class="gmail_quote">On Mon, Oct 4, 2010 at 9:08 AM, David van der Spoel <span dir="ltr">&lt;<a href="mailto:spoel@xray.bmc.uu.se">spoel@xray.bmc.uu.se</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On 2010-10-01 10.28, Roland Schulz wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<br>
On Fri, Oct 1, 2010 at 3:35 AM, Mark Abraham &lt;<a href="mailto:mark.abraham@anu.edu.au" target="_blank">mark.abraham@anu.edu.au</a><br></div><div class="im">
&lt;mailto:<a href="mailto:mark.abraham@anu.edu.au" target="_blank">mark.abraham@anu.edu.au</a>&gt;&gt; wrote:<br>
<br>
<br>
<br>
    ----- Original Message -----<br></div><div class="im">
    From: Roland Schulz &lt;<a href="mailto:roland@utk.edu" target="_blank">roland@utk.edu</a> &lt;mailto:<a href="mailto:roland@utk.edu" target="_blank">roland@utk.edu</a>&gt;&gt;<br>
    Date: Friday, October 1, 2010 16:58<br>
    Subject: Re: [gmx-developers] Collective IO<br>
    To: Discussion list for GROMACS development<br></div><div><div></div><div class="h5">
    &lt;<a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a> &lt;mailto:<a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a>&gt;&gt;<br>
<br>
     &gt;<br>
     &gt;<br>
     &gt; On Thu, Sep 30, 2010 at 9:19 PM, Mark Abraham<br>
    &lt;<a href="mailto:mark.abraham@anu.edu.au" target="_blank">mark.abraham@anu.edu.au</a>&gt; wrote:<br>
<br>
         &gt;<br>
         &gt;<br>
         &gt; ----- Original Message -----<br>
         &gt; From: Roland Schulz &lt;<a href="mailto:roland@utk.edu" target="_blank">roland@utk.edu</a>&gt;<br>
         &gt; Date: Friday, October 1, 2010 9:04<br>
         &gt; Subject: Re: [gmx-developers] Collective IO<br>
         &gt; To: Discussion list for GROMACS development<br>
        &lt;<a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a>&gt;<br>
         &gt;<br>
         &gt; &gt;<br>
         &gt; &gt;<br>
         &gt; &gt; On Thu, Sep 30, 2010 at 6:21 PM, Szilárd Páll<br>
        &lt;<a href="mailto:szilard.pall@cbr.su.se" target="_blank">szilard.pall@cbr.su.se</a>&gt; wrote:<br>
<br>
             &gt; &gt; Hi Roland,<br>
             &gt; &gt;<br>
             &gt; &gt; Nice work, I&#39;ll definitely take a look at it!<br>
             &gt; &gt;<br>
             &gt; &gt; Any idea on how does this improve scaling in general<br>
            and at what<br>
             &gt; &gt; problem size starts to really matter? Does it introduce<br>
            and overhead<br>
             &gt; &gt; in smaller simulations or it is only conditionally<br>
            turned on?<br>
<br>
         &gt; &gt;<br>
         &gt; &gt; At the moment it is always turned on for XTC when compiled<br>
        with MPI. In serial or with threads nothing changes. At the<br>
        moment we buffer at maximum 100 frames. If one uses less than<br>
        100 PP nodes than we buffer as many frames as the number of PP<br>
        nodes. We also make sure that we don&#39;t buffer more than 250MB<br>
        per node.<br>
         &gt; &gt;<br>
         &gt; &gt; The 100 frames and 250MB are both constants which should<br>
        probably still be tuned.<br>
         &gt;<br>
         &gt; Indeed - and the user should be able to tune them, too. They<br>
        won&#39;t want to exceed their available physical memory, since<br>
        buffering frames to virtual memory (if any) loses any gains from<br>
        collective I/O.<br>
<br>
     &gt; Honestly we hadn&#39;t thought much about the 250MB limit. We first<br>
    wanted to get feedback on the approach and the code before doing<br>
    more benchmarks and tuning these parameters. It is very likely that<br>
    their are no cases which benefit from using more than 2MB per MPI<br>
    process.<br>
     &gt;<br>
     &gt; In case we limit the memory usage to 2MB should we still make it<br>
    configurable? I think adding to many mdrun option gets confusing.<br>
    Should we make the number of buffered frames a hidden mdrun option<br>
    or an environment variable (the default would be that the number is<br>
    auto-tuned)?<br>
<br>
    Hmmm. 2MB feels like quite a low lower bound.<br>
<br>
The buffering is done on every node before the data is collected to the<br>
IO nodes. Thus if you e.g. have 1000 nodes each buffering 2MB and you<br>
have 20 IO nodes each IO node gets 100MB.<br>
The IO requirement of an IO node is the same as it is currently for the<br>
master. A whole frame has to fit into memory (an IO node never has more<br>
than one frame). This can of course be a problem but it is independent<br>
of the current approach.<br>
As soon as someone writes code which allows to write a single frame in<br>
parallel this can be easily combined with our buffering approach and<br>
would overcome this memory requirement.<br>
<br>
Thus our approach doesn&#39;t improve the current memory requirement. But it<br>
also doesn&#39;t increases the memory per process ( &lt;2MB) significantly.<br>
<br>
Currently more than one IO node e (=1 MPI task on one core) can be<br>
placed on one physical node. We will improve this and limit it to one IO<br>
node per physical node (thus only maximum one core participates in the<br>
collective IO). This makes sure that also the total memory per shared<br>
memory node doesn&#39;t increase significantly.<br>
<br>
    Collective I/O requires of the order of several MB per process per<br>
    operation to be worthwhile.<br>
<br>
yes. The IO nodes have that as long as one frame is not too small. For<br>
very small frames/few atoms Collective IO shouldn&#39;t be important. But<br>
performance might still improve because the XTC compression is done in<br>
parallel and the write frequency is reduced.<br>
<br>
    OTOH you don&#39;t want to buffer excessively, because that loses more<br>
    when hardware crashes occur. You do have the checkpoint interval as<br>
    another upper bound, so that&#39;s probably fine. 250MB concerned me,<br>
    because the BlueGene cpus have up to about 1GB per cpu...<br>
<br>
<br>
    I think a hidden option is probably best.<br>
<br>
OK. We do that (unless their&#39;ll be other opinions).<br>
<br>
Roland<br>
<br>
</div></div></blockquote>
Hi Ryan &amp; Roland, great stuff!<br>
<br>
I&#39;m giving a gromacs talk in an hour and will mention this immediately! Have you also tested PME? It would be interesting if the performance with PME also increases by 13 ns/day for the same setup...<br></blockquote>

<div>PME won&#39;t scale to 8000 cores for 3M atoms. But for a problem size for which PME scales the speed-up should be the same. </div><div>Also we (Berk &amp; me) will probably have an improved version of PME (with threads) ready by the end of the week. This should help a lot for the PME scaling at this scale. And thus make the IO change more important even with PME for more problem sizes.</div>

<div><br></div><div>Roland</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
-- <br>
David van der Spoel, Ph.D., Professor of Biology<br>
Dept. of Cell &amp; Molec. Biol., Uppsala University.<br>
Box 596, 75124 Uppsala, Sweden. Phone:  +46184714205.<br>
<a href="mailto:spoel@xray.bmc.uu.se" target="_blank">spoel@xray.bmc.uu.se</a>    <a href="http://folding.bmc.uu.se" target="_blank">http://folding.bmc.uu.se</a><br><font color="#888888">
-- <br></font><div><div></div><div class="h5">
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don&#39;t post (un)subscribe requests to the list. Use the www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov">cmb.ornl.gov</a><br>865-241-1537, ORNL PO BOX 2008 MS6309<br>