I believe the procedural arguments are the most worrying thing, and they haven't been commented on, which is a bit worrying. Nor has the fact that the proposal, even with *TWO* corrections which are separate proposals, still isn't complete (in that user callbacks which should be const aren't because we're rushing this through 2.2 instead of working in the 3.0 framework, where we could make minor user code changes like correcting const in the callbacks. But in response to your question, Open MPI does have a test suite, and we can use the ANL and Intel test suites. However, none of them test that we're handing const correctly. They test that the behavior according to MPI-2.1 is correct. They don't check that there are const keywords in the right place. Such a change would be fairly large (to the test suite, that is), which only adds to the "largeness" of this patch. We're not ignoring your statement of 2.5 hours. But I don't think that's a realistic metric for doing the implementation, updating/developing test cases, and properly testing on a variety of compilers. Both Jeff and I have asked essentially the same question, without a reasonable answer. Why are we pushing a proposal with known procedural issues and possibly oversized implementation into 2.2 when it can easily be pushed to 3.0? What's the rush - let's do this completely and correctly the first time, rather than looking like fools in two months when it turns out we did something wrong. Brian On 3/19/09 9:50 , "Erez Haba" <erezh_at_[hidden]> wrote:

Jeff, I don't understand why you ignore all the work that has been done with this ticket and suggest your own metric. Was the information I provided unreliable or untrue?

As I said, it took me about 2.5h to implement the entire change on the MSMPI code base; yes there were many internal functions that had const in it, but also many that did not. I don't think that by any measure this is a significant work for any implementer.

More than that, this interface change was tested using the ANL test suite and the Intel complete test suite, without a single compile or runtime error over multiple platforms and compilers. Again, this was not a significant work item; and I believe that OpenMPI has a regression suite that crosses platform and compilers which is easy to run (as you described to me many times).

With this information that I have already provided before, I don't understand your claims; unless you think that they are biased and unreliable.

Hence this ticket completely meets MPI 2.2 requirements in scope and backward compatibility.

Thanks, .Erez

-----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Thursday, March 19, 2009 5:20 AM To: Bronis R. de Supinski; MPI 2.2 Subject: Re: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation

On Mar 19, 2009, at 12:03 AM, Bronis R. de Supinski wrote:

...

I have been quiet on this debate but I am to the point that I feel a need to speak up. I think the "significant changes" reason is a canard (I think Brian and Jeff believe it but it is still a red herring for the most part). The changes to support it are not significant. You can implement it by casting it away early.

The changes *are* significant. I count 90 top-level MPI API functions that are affected by this proposal.

The bar for 2.2 is "trivial" implementation efforts, no? This is not trivial. The MPICH diff was ~10,000 lines. Apparently, they chose to go above and beyond the requirement and propagate const to lower layers (vs. casting it away immediately), but still -- if a 2.2 change can inspire a 10,000 line diff, that just seems like it doesn't meet the spirit of the "trivial" implementation requirement.

Indeed, in doing the "simple" cast-it-away-immediately approach implementation, editing and testing each of the 90 functions will require a good amount of effort. Sure, the first-wave addition of "const" across all of the affected functions is probably relatively easy -- one code monkey and several hours. But how long will it take you to find the one place where you put "const" in the wrong location? How long will it take you to write new tests to verify the const-ness in all the right places? To be clear: it's a "not significant" change to a code monkey. But try to tell your QA guys that this is not significant -- they'll freak out.

Hence, if you take the overall scope of both the change and the additional testing to validate this change, this is a large scale implementation effort. I just don't see what the rush is to get this into 2.2.

I think Brian makes several good arguments, one of which is: those who want const can put it in today. It hypothetically shouldn't break any existing user codes (this is the code monkey in me talking, not the QA rep), and those implementors who want it for stronger contracts can have it.

-- Jeff Squyres Cisco Systems

_______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

_______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22

-- Brian W. Barrett Dept. 1423: Scalable System Software Sandia National Laboratories