From bronis@XXXXXXXX Wed Jan 9 15:52:03 2008 Delivered-To: mpifrm-mpi-21-outgoing@XXXXXXXXXXXXXXXXXXXXXXX X-Original-To: mpifrm-mpi-21@XXXXXXXXXXXXXXXXXXXXXXX Delivered-To: mpifrm-mpi-21@XXXXXXXXXXXXXXXXXXXXXXX X-Attachments: None X-IronPort-AV: E=McAfee;i="5100,188,5203"; a="6296311" X-IronPort-AV: E=Sophos;i="4.24,264,1196668800"; d="scan'208";a="6296311" Date: Wed, 9 Jan 2008 13:51:55 -0800 (PST) From: "Bronis R. de Supinski" To: mpi-21@XXXXXXXXXXXXX Subject: RE: [mpi-21] Proposal EH2: add const keyword to the C bindings In-Reply-To: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mailbouncer.mcs.anl.gov Sender: owner-mpi-21@XXXXXXXXXXXXX Precedence: bulk Reply-To: mpi-21@XXXXXXXXXXXXX X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mailbouncer.mcs.anl.gov Dick: Re: > I think it is likely the forum will conclude that the send buffer access > rules should be relaxed but there should be more to the discussion than > "Do you care about users or don't you?" I have been silent on this question up to now. I have taken the opinion that if some want to spend their time creating solutions to non-problems that will eventually be discarded then then let them. However, it is quickly proving that alot of other people's time will be consumed by this. I have implemented a lot of MPI code. I work with many serious MPI application and library programmers. I have implemented tools that detect MPI programming errors. I have several people who use that tool and find it helpful. I have read many papers on the subject of MPI coding errors. I have seen some pretty bizarre MPI errors. Not ONCE have I heard that "Restricted access to buffers of non-blocking MPI send operations was the source of my problem." Not only do implementations not take advantage of the opportunity, the restriction is NOT violated. This issue is not worth the time it is being given until someone can do more than state that it must be causing problems for "many applications and commercial applications." I see no reason to sacrifice any potential performance for something no one slips on. As a representative of the user committee, I intend to vote AGAINST these proposed changes. Bronis