<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">On the copy step, I wonder if a code that tried harder to work with aligned blocks and in the parallel case tried to avoid conflicts between processors would be valuable. It might be an interesting class exercise: Given the needs here (which may be unaligned segments), design, implement, verify, and measure the performance of an implementation of the parallel move operation. The winning code could become part of pnetCDF (and perhaps part of netCDF as well). <DIV><BR class="khtml-block-placeholder"></DIV><DIV>Are there other places in the pnetCDF code where it might be valuable to either explicitly align and block the I/O, or ensure that the MPI-IO call has enough to work with so that a high-quality MPI-IO implementation would do the same?<DIV><BR class="khtml-block-placeholder"></DIV><DIV>Bill</DIV><DIV><BR><DIV><DIV>On Dec 5, 2006, at 3:06 PM, Robert Latham wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P> <BLOCKQUOTE type="cite"><P style="margin: 0.0px 0.0px 0.0px 10.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">Also, the 4096 is used <SPAN class="Apple-converted-space"> </SPAN></FONT></P> <P style="margin: 0.0px 0.0px 0.0px 10.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">as the buffer size in MPI_File_read_at and similar calls (this seems <SPAN class="Apple-converted-space"> </SPAN></FONT></P> <P style="margin: 0.0px 0.0px 0.0px 10.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">rather small).<SPAN class="Apple-converted-space"> </SPAN>Should this buffer size be negotiated? (I'm wondering <SPAN class="Apple-converted-space"> </SPAN></FONT></P> <P style="margin: 0.0px 0.0px 0.0px 10.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">if this might be a source of the slowdown that we're seeing, as this <SPAN class="Apple-converted-space"> </SPAN></FONT></P> <P style="margin: 0.0px 0.0px 0.0px 10.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">code can be invoked during a close).</FONT></P> </BLOCKQUOTE><P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica; min-height: 14.0px"><BR></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">I covered most of this in my reply to Katie's message.<SPAN class="Apple-converted-space"> </SPAN>I don't know</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">what a good value would be for this:<SPAN class="Apple-converted-space"> </SPAN>no matter how big we make it, if</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">the caller mucks with the header and forces us to shuffle all the bits</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">in the datafile, it's going to be slow.<SPAN class="Apple-converted-space"> </SPAN>Additionally, both we and serial</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">netcdf strongly encourage everyone to do all their defining once, so</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">is it worth constructing a lot of negotiation infrastructure for a</FONT></P> <P style="margin: 0.0px 0.0px 0.0px 0.0px"><FONT face="Helvetica" size="3" style="font: 12.0px Helvetica">hopefully infrequenlty used code path? <SPAN class="Apple-converted-space"> </SPAN></FONT></P> </BLOCKQUOTE></DIV><BR></DIV></DIV></BODY></HTML>