Hi all, here are my notes from today's telecon. They are also in the wiki (http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/Telecon041008) Please feel free to post additions or corrections and edit the wiki! Attendees (alphabetically): * Greg Bronevetsky (LLNL) * Torsten Hoefler (IU) * Bin Jia (IBM) * Andrew Lumsdaine (IU) * Amith Mamidala (OSU) * Adam Moody (LLNL) * Hans-Joachim Plum (Intel) * Christian Siebert (NEC) * Jesper Larsson Traff (NEC) * Rolf VandeVaart (Sun) Agenda 1. Schedule regular meeting time and interval 2. Updates on Non-blocking collectives - Torsten 1. revisiting tags 2. the interface (naming) 3. using MPI_Requests? 4. matching (rescue it?) 5. Free/Cancel? 3. Updates on Topological/Sparse Collectives 1. more than one neighbor per direction 2. Neighbor_allreduce 3. proposing changed graph interface officially 4. Dynamically-sized collective operations 1. malloc vs. upper bounded memory 2. new interface functions vs. changed semantics 5. Persistent Collectives 6. New Collective Ops 7. Modularity Discussion Notes 1. regular meetings will be on Thursdays 12pm once between two face to face meetings, might be more often later 2. topological collectives, we don't want to distinguish between graph and Cartesian communicators (Torsten) 1. do the more than one neighbor per direction via a conversion from Cartesian communicators to graph communicators (Torsten) 2. weather codes use "more than one neighbor", also non-symmetric (Adam) 3. but we don't want to double the function interfaces (Torsten) 4. do better analysis of codes (Adam) 5. consensus on Neighbor_allreduce 6. how do we optimize it? (Jesper) 7. changes to graph interface? We decided to write a proposal down, add Info object (Jesper and Torsten go off) 8. Allgather will be added to the proposal later 3. Non-blocking collectives 1. nobody spoke up for tags, so they're dropped officially now 2. naming conventions, "I" might be confusing but we can just define it clearly (Torsten) 3. Jesper proposes "N" as new name 4. using MPI_Requests would be helpful/more consistent (Torsten) 5. problems with Cancel/Free will occur (Adam, Alexander) 6. we can just stick to the current definition of Cancel which only defines send/recv clearly (Alexander) 7. Free would be useful too, could stick to the current definition (Alexander, Torsten) 8. we all agree to not allow matching 9. Cancel might also have problems with hardware support 10. Cancel should not be enforced but still be defined for implementations that can do it (might fail) 4. dynamic collectives might limit performance if used at places where one could use normal collectives (Adam) 1. we need an advice to users there 2. we need to add a new interface (max data-size is not in the old interface), old interface might limit scalability (huge arrays on huge communicators) 3. add also non-blocking versions of those operations 5. persistent collectives are useful 1. defined similarly to send/recv 2. matching persistent and non-persistent could limit optimization -> no matching 3. Alexander, Christian and Torsten go off and write it down 4. we need ordering in Startall now (changes semantics of other calls) 5. should tehy be part of non-blocking ops or not (subsetting)? -> we should have a separate module for persistent ops All the Best, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Indiana University | http://www.indiana.edu Open Systems Lab | http://osl.iu.edu/ 150 S. Woodlawn Ave. | Bloomington, IN, 474045-7104 | USA Lindley Hall Room 135 | +01 (812) 855-3608