Dear Brian, Thank you. From the implementor's point of you, to be consistent, we probably should prohibit access to the engaged 1-sided buffers as well. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Barrett, Brian W Sent: Wednesday, December 10, 2008 5:32 AM To: MPI 2.2 Subject: Re: [Mpi-22] please review - Send Buffer Access (ticket #45) For reasons I'm not sure I completely understand, the discussion on this proposal has become focused on micro-optimizations for MPI implementations, rather than the original desire to fix one of the many usability complaints users have with the MPI standard. I personally believe that the send buffer restriction places an onerous burden on the developer of modern MPI applications. While it's straight-forward to ensure a buffer is not used multiple times for simple ghost cell transfers in basic physics codes, it can be more challenging in more advanced applications. We already know of one application in the wild that reuses send buffers (the Parallel BGL). I'm certain that if we polled application writers, we'd find even more which violate the restriction. Even as an MPI implementer who knows what he's doing (in theory, anyway), I find this restriction can be a difficult problem to work around. Further, this is a difficult issue to detect. Yes, a correctness-checking library can track buffers in use. But consider that buffer reuse is likely to be quite transient, and correctness-checking libraries frequently have an extraordinary performance penalty. Normal development cycle testing likely won't cause the issue to appear, since no current mainstream MPI implementation enforces the rule and I'm doubtful that situation will change. Finally, from a user's perspective, it must look rather capricious of the standards committee that a send buffer can't be reused but a one-sided buffer can. I certainly couldn't justify to a user why the standard has such a contradiction. Do we as a committee have the right to be capricious on this issue? Certainly. Should we then wonder why there are so many people running around preaching the evils of MPI? Certainly not. So in my opinion the question really should be framed not as "Is there any optimization that such a change prohibits?", but "Does the usability of the standard outweigh the loss of *potential* optimizations?". I have to think that eliminating a common source of confusion for users is worth losing the ability to increase the performance of sending so many giga-zeros of data. Brian -- Brian W. Barrett Dept. 1422: Scalable Computer Architectures Sandia National Laboratories _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.