From treumann@XXXXXXXXXX Thu Jan 10 09:30:43 2008 Delivered-To: mpifrm-mpi-21-outgoing@XXXXXXXXXXXXXXXXXXXXXXX X-Original-To: mpifrm-mpi-21@XXXXXXXXXXXXXXXXXXXXXXX Delivered-To: mpifrm-mpi-21@XXXXXXXXXXXXXXXXXXXXXXX In-Reply-To: <33DA4822-5AFD-46DD-B3BC-034A76867501@XXXXXXXXXXXX> Subject: Re: [mpi-21] Proposal EH2: add const keyword to the C bindings To: mpi-21@XXXXXXXXXXXXX X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Richard Treumann Date: Thu, 10 Jan 2008 08:53:41 -0500 X-MIMETrack: Serialize by Router on D01ML064/01/M/IBM(Release 7.0.2FP2 IGS702FP2HF5|November 8, 2007) at 01/10/2008 08:53:43 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBF95FDFDB534A8f9e8a93df938690918c0ABBF95FDFDB534A" Content-Disposition: inline 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 X-Spam-Status: No, hits=-0.6 tagged_above=-1.0 required=5.3 tests=AWL, BAYES_00, HTML_00_10, HTML_MESSAGE X-Spam-Level: --0__=0ABBF95FDFDB534A8f9e8a93df938690918c0ABBF95FDFDB534A Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I have mentioned that I think the proposal for removing the send buffer= access restriction is worth examining. I have even said I think it lik= ely (not obvious) that the rule should be relaxed. First we should conclud= e that keeping it has trivial potential for being important to some MPI implementation in comparison the burden it puts on application writers.= Performance matters a lot and always will. I thank those who provided examples of situations where relaxed send bu= ffer rules would be helpful. From the start of this discussion I have assumed there would be defensi= ble parallel algorithms that tempt the programmer to violate the rule. I ha= ve also assumed there are probably some programmers who violate the rule,= either because they do not know about it or because they think they kno= w enough to be sure the rule is irrelevant. I did not have a good estima= te of how often the rule is a potential problem but I did see how it could= matter. Finally, I think that unless the problems the send buffer rule creates = for MPI application writers are real and significant, we should lean toward= keeping it. If we let it go to solve hypothetical problems and later develop an architecture that could really exploit the freedom the rule provides to implementors, we will be unable to get the rule back. Dick BTW - I do not see that the decision about the send buffer rule has muc= h connection to "Proposal EH2: add const keyword to the C bindings". In = my opinion, the two discussions should be kept apart . I will tackle the "const" issue in a new thread. The send buffer rule seems to have becom= e the dominant topic of this thread. Dick Treumann - MPI Team/TCEM IBM Systems & Technology Group Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363= --0__=0ABBF95FDFDB534A8f9e8a93df938690918c0ABBF95FDFDB534A Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I have mentioned that I think the proposal for removing the send buf= fer access restriction is worth examining. I have even said I think it= likely (not obvious) that the rule should be relaxed. First we should= conclude that keeping it has trivial potential for being important to = some MPI implementation in comparison the burden it puts on application= writers. Performance matters a lot and always will.

I thank those who provided examples of situations where relaxed send bu= ffer rules would be helpful.

From the start of this discussion I have assumed there would be defensi= ble parallel algorithms that tempt the programmer to violate the rule. = I have also assumed there are probably some programmers who violate th= e rule, either because they do not know about it or because they think = they know enough to be sure the rule is irrelevant. I did not have a g= ood estimate of how often the rule is a potential problem but I did see= how it could matter.

Finally, I think that unless the problems the send buffer rule creates = for MPI application writers are real and significant, we should lean to= ward keeping it. If we let it go to solve hypothetical problems and la= ter develop an architecture that could really exploit the freedom the r= ule provides to implementors, we will be unable to get the rule back.
Dick

BTW - I do not see that the decision about the send buffer rule has muc= h connection to "Proposal EH2: add const keyword to the C bindings= ". In my opinion, the two discussions should be kept apart . I wi= ll tackle the "const" issue in a new thread. The send buffer = rule seems to have become the dominant topic of this thread.

Dick Treumann - MPI Team/TCEM
IBM Systems & Technology Group
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846 Fax (845) 433-8363
= --0__=0ABBF95FDFDB534A8f9e8a93df938690918c0ABBF95FDFDB534A--