By the definition of complexity which I alluded to in one message, I think
that non-blocking collectives have a complexity of nearly zero, at least for
the user. That is, the user already knows how non-blocking operations work,
and they already know how collective operations work, and these appear to be
orthogonal concepts. As long as there is no additional information to learn
or remember besides these two orthogonal concepts to understand their
combination, the user is using what they already know to get new, possibly
useful, functionality. (This is why, in my original message, I made the point
that complexity was not necessarily related to the number of functions.) In
fact, by this definition, adding a PROBE-like function to deal with the
absence of these non-blocking collectives *might* add complexity and new
things for the user to remember, especially if this new function somehow
looked or acted different from existing PROBE functions.
This does not speak to the internal complexity that might be added by
implementing non-blocking collectives. Others can address that better
than I can.
This also does not take into account any other discussions which might have
occurred at the meeting or elsewhere on the topic. I am just making sure
that my original point was not misunderstood.
David C. DiNucci | MRJ, Inc., Rsrch Scntst | NASA Ames Rsrch Ctr
email@example.com| NAS (Num. Aerospace Sim.)| M/S T27A-2
(415)604-4430 | Parallel Tools Team | Moffett Field, CA 94035