Hi,

Thanks. As soon as there's a couple of non-blocking recvs out there, waiting for them in reverse order requires tracking of the moment when the receives were posted. In some cases this leads to extra fields and data exchanges. How's that different from multiple Recvs in multiple threads. Hmm, I guess the threaded case is just undefined and the implementation is allowed to ignore ordering, right?

The footprint argument generally says that the library will be smaller. This may be a minor matter for general purpose computers, but as soon as you go to Petascale, you need every byte on the compute nodes for user data, especially if dynamic libraries are not supported. ack

As for the collectives, many are implemented using SendRecv, and that blocking call in turn often uses non-blocking communication. Classic Alltoallv algorithm uses nonblocking calls, too. So, I'm not sure that even unoptimized blocking collectives will always use only blocking pt2pt. Yes, of course - again, the proposed "interface" is more of a logical nature. You can implement all blocking collectives with blocking p2p (it'll be slower). But ok, pulling all p2p functions in this interface is also unproblematic. So I don't really have a srong opinion here.

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