<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi all,<br>
<br>
I attached the slides that I presented at the Forum, and here are
some notes I took when discussing the proposals:<br>
<br>
Collective I/O ticket:<br>
<ul>
<li>Need a more compelling reason to add them to the standard.
Maybe a more in-depth study and demand from users with use
cases. <br>
</li>
<li>Implementation of split collectives hard as is, so to add a
harder interface for implementers needs to be justified.</li>
<li>Will not attempt to deprecate the split collective in this
ticket.</li>
</ul>
<p>Asynchronous MPI Model:<br>
</p>
<ul>
<li>discuss whether it makes sense to introduce such a model in
MPI</li>
<li>Can something be done with generalized request.<br>
</li>
<li>a more thorough study should be conducted on what internal MPI
features get exposed </li>
<li>Should consider an implementation path for MPI that does not
have threads.</li>
<li>No overhead should be introduced, which might not be the case
with RMA</li>
</ul>
<p>Independent File View changes:<br>
</p>
<ul>
<li>The file_set_view operation should be used to do optimizations
(collectively), so adding an independent version would urge
developers to not "do the right thing" with the original
routine.<br>
</li>
<li>what happens in some cases when all processes set the file
view collectively, then 1 process changes its file view
independently? How would the other processes know that? The MPI
library might need to communicate that change to other processes
if the original set file_view did certain optimizations.<br>
</li>
<li>For our use case, we can introduce a flag on File open, that
says set_view is always independent or collective. We can
introduce also another collective routine to allow the user to
change set_view from independent to collective and vice versa.</li>
</ul>
<p>Grouped I/O operations:<br>
</p>
<ul>
<li>A file_reopen with a sub group is a feasible solution, but
more though needs to be taken into consideration..<br>
</li>
<li>What are the consistency semantics for the new file handle
that is returned with open_grouped. this needs to be examine
more.</li>
<li>What happens if you opened the file twice, but with a
different communicator? Can MPI optimize that?</li>
<li>This also affects the file view that is set for the original
file handle. How would that play out now? allow grouped file
view changes on the new handle, or just allow independent file
changes?</li>
<li>do some benchmarking with existing MPI implementations to see
performance of Opening file multiple times.</li>
</ul>
<p>Shared FP bug:<br>
</p>
<ul>
<li>emphasize the offset returned should be for where access
started.</li>
<li>go over all routines for shared file pointers and indicate why
only those three were chosen. We can add a position returned to
the ordered operation, it just seemed easy for the user to be
able to retrieve it.</li>
<li>generally seemed ok, but needed to emphasize use cases more in
proposal.<br>
</li>
</ul>
<p>Thanks,<br>
Mohamad<br>
</p>
</body>
</html>