Hi Torsten, The two key areas I'd like to work with our users on here at LLNL are non-blocking and neighbor-exchange (topological) collectives. I could perhaps also look into the benefits of persistent collectives. Our users would like to start using non-blocking collectives asap -- they are excited about this. I suspect we'll be able to show some real value for the neighbor-exchange collectives on our clusters, as well. And given IB's need to pin memory, we may also be show performance gains with persistent collectives. For non-blocking collectives, should I start with libNBC? Where can I get the latest copy of it? I know you have done some work with neighbor-exchange collectives, too. Do you have a similar library for that? -Adam Torsten Hoefler wrote:
Hello Collectives-WG, we propose
July 31, 12:00pm EDT
as the time/date for our monthly collectives workgroup teleconference.
Please let us know if there are any strong objections.
We will mainly be talking about the feedback we got from the whole forum on our proposals. My notes are at: https:// svn.mpi-forum.org/trac/mpi-forum-web/wiki/forum063008
Im particular we have to decide (those points also serve as agenda items):
1) "One call fits all" vs. "Calls for everything: - we should make a decision on which model we want to use in order to be able to flesh out semantic details of the operations 2) Do we want/need all combinations that are semantically possible? - the Forum accepted the usefulness of non-blocking collectives as proved - the Forum wants to see more research/use cases for sparse collectives - the Forum wants to see more research/use cases for persistent colls - who wants to invest time into this? 3) Updates on topological collectives 4) Updates on MPI Plans (I have a slightly different proposal/implementation than Christian for the same thing) 5) Variable size collectives (does anyone pick this topic up?) 6) MPI-2.2 issues (I will add the WG's proposals to the MPI-2.2 wiki so that this can serve as a base for discussion) a) fix non-scalable graph interface (obvious) b) local reduction operation (needed by libraries, e.g., LibNBC) c) local progress function (caused heavy discussions in Forum) d) request completion callbacks (for better progression, e.g., LibNBC) e) partial pack/unpack (needed by libraries, e.g., LibNBC) 7) other items
Please post any additional proposals items to discuss to the list!
Thanks & Best, Andrew Lumsdaine and Torsten Hoefler