<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Let's not invoke emotion here; there are valid tech and procedural questions that have been raised multiple times. Its always the burden of the proposer to answer such questions - this is no different than any other proposal. Indeed, I think torsten's nbc proposal received *much* more scrutiny than this.<BR>
<BR>
- This may have been one of the first / oldest tickets, but it sat there for a long time with no action from you until we're nearly out of time for mpi 22. Using the "its a year old" argument isn't valid.<BR>
<BR>
- an open source implementation is *required* for mpi 22.<BR>
<BR>
- testing that const is in the right places in the interface is *exactly* the right kinds of tests to write.<BR>
<BR>
-jms<BR>
Sent from my PDA. No type good.<BR>
<BR>
----- Original Message -----<BR>
From: mpi-22-bounces@lists.mpi-forum.org <mpi-22-bounces@lists.mpi-forum.org><BR>
To: MPI 2.2 <mpi-22@lists.mpi-forum.org><BR>
Sent: Thu Mar 19 18:00:33 2009<BR>
Subject: Re: [Mpi-22] Ticket #46: Add const Keyword to the C bindings-implementation<BR>
<BR>
Terry, I'm truly sorry that you find the information that I provide as unreliable. I know that I'm not part of the 'trusted' OpenMPI clan and I wish that there was something I could do to convince you otherwise.<BR>
<BR>
If you recall the last forum meeting, I did a complete implementation of the 'const' ticket during that meeting. (and did let everyone know about it). That was an implementation from scratch that did trickle down the constness to all the internal functions of MSMPI. Indeed I did not do any runtime testing at that meeting, it did happen later. However, since MSMPI is not an open source project, I asked the friends at ANL to re-implement it over MPICH2 and make the source available. Since you might not trust my word, you may ask Rajeev and other friends at ANL about this.<BR>
<BR>
<BR>
The tests conducted were checking for regression. Hence, any program that compiled and run correctly before the const change did compile and run correctly after the const change; with multiple compiler and multiple operating systems. We did not conduct any direct tests that are checking the 'constness' of the interface.<BR>
I don't really know how you check for constness? Do you check that the buffer was not modified? Well that would be testing ticket #45 (send buffer access) and not ticket #46. Do you check that you pass const in and you don't get a compiler error? that relatively simple and I don't think it buys you much (except it verifies that you put the const in all the right places on the interface API).<BR>
<BR>
As to rushing this in, I'm curious, this ticket is there for over a year; already implemented twice and tested by two different bodies. Is this really rushing it in?<BR>
<BR>
As to the procedural issues. This ticket is one of the first tickets that we had in the system, and of-course as the mpi forum body we did learn a thing or two in that process, unfortunately, first implemented with that ticket. So yes there would be issues. I think that we can resolve these 'issues' but puting dependency on passing this ticket given that we accept the other two corrections to the ticket.<BR>
<BR>
<BR>
Thanks,<BR>
.Erez<BR>
<BR>
-----Original Message-----<BR>
From: mpi-22-bounces@lists.mpi-forum.org [<A HREF="mailto:mpi-22-bounces@lists.mpi-forum.org">mailto:mpi-22-bounces@lists.mpi-forum.org</A>] On Behalf Of Terry Dontje<BR>
Sent: Thursday, March 19, 2009 9:15 AM<BR>
To: MPI 2.2<BR>
Subject: Re: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation<BR>
<BR>
I am not Jeff and I do not play him on tv but I felt the need to<BR>
interject my 2 cents.<BR>
<BR>
Erez Haba wrote:<BR>
> 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?<BR>
><BR>
> <BR>
Possibly but it definitely is biased IMO.<BR>
> 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.<BR>
><BR>
> <BR>
Isn't MSMPI based on MPICH? If so how much of the previous work done to<BR>
support const did you leverage or did you truly reinvent the same wheel<BR>
MPICH developers did? I guess I find it pretty amazing the applying<BR>
10,000 lines of changes and then validating them took you 2.5 hours.<BR>
> 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).<BR>
><BR>
><BR>
> <BR>
Do the ANL tests and any others really test const-ness without changes. <BR>
Or are you saying the ANL tests already do explicit testing of<BR>
const-ness on the right parameters?<BR>
> With this information that I have already provided before, I don't understand your claims; unless you think that they are biased and unreliable.<BR>
><BR>
> <BR>
I would say your information is a useful datapoint but I am curious if<BR>
what you did really was the full conversion of your MPI implementation<BR>
to handle this change.<BR>
> Hence this ticket completely meets MPI 2.2 requirements in scope and backward compatibility.<BR>
><BR>
> <BR>
For MPICH based implementations I agree it does. For Open MPI I think<BR>
it is still questionable. I guess I am still interested in the<BR>
reasoning why shoving this ticket into 2.2 is such a high priority?<BR>
<BR>
--td<BR>
> Thanks,<BR>
> .Erez<BR>
><BR>
> -----Original Message-----<BR>
> From: mpi-22-bounces@lists.mpi-forum.org [<A HREF="mailto:mpi-22-bounces@lists.mpi-forum.org">mailto:mpi-22-bounces@lists.mpi-forum.org</A>] On Behalf Of Jeff Squyres<BR>
> Sent: Thursday, March 19, 2009 5:20 AM<BR>
> To: Bronis R. de Supinski; MPI 2.2<BR>
> Subject: Re: [Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation<BR>
><BR>
> On Mar 19, 2009, at 12:03 AM, Bronis R. de Supinski wrote:<BR>
><BR>
> <BR>
>> I have been quiet on this debate but I am to the point<BR>
>> that I feel a need to speak up. I think the "significant<BR>
>> changes" reason is a canard (I think Brian and Jeff<BR>
>> believe it but it is still a red herring for the most<BR>
>> part). The changes to support it are not significant.<BR>
>> You can implement it by casting it away early.<BR>
>><BR>
>> <BR>
><BR>
><BR>
> The changes *are* significant. I count 90 top-level MPI API functions <BR>
> that are affected by this proposal.<BR>
><BR>
> The bar for 2.2 is "trivial" implementation efforts, no? This is not <BR>
> trivial. The MPICH diff was ~10,000 lines. Apparently, they chose to <BR>
> go above and beyond the requirement and propagate const to lower <BR>
> layers (vs. casting it away immediately), but still -- if a 2.2 change <BR>
> can inspire a 10,000 line diff, that just seems like it doesn't meet <BR>
> the spirit of the "trivial" implementation requirement.<BR>
><BR>
> Indeed, in doing the "simple" cast-it-away-immediately approach <BR>
> implementation, editing and testing each of the 90 functions will <BR>
> require a good amount of effort. Sure, the first-wave addition of <BR>
> "const" across all of the affected functions is probably relatively <BR>
> easy -- one code monkey and several hours. But how long will it take <BR>
> you to find the one place where you put "const" in the wrong <BR>
> location? How long will it take you to write new tests to verify the <BR>
> const-ness in all the right places? To be clear: it's a "not <BR>
> significant" change to a code monkey. But try to tell your QA guys <BR>
> that this is not significant -- they'll freak out.<BR>
><BR>
> Hence, if you take the overall scope of both the change and the <BR>
> additional testing to validate this change, this is a large scale <BR>
> implementation effort. I just don't see what the rush is to get this <BR>
> into 2.2.<BR>
><BR>
> I think Brian makes several good arguments, one of which is: those who <BR>
> want const can put it in today. It hypothetically shouldn't break any <BR>
> existing user codes (this is the code monkey in me talking, not the QA <BR>
> rep), and those implementors who want it for stronger contracts can <BR>
> have it.<BR>
><BR>
> <BR>
<BR>
_______________________________________________<BR>
mpi-22 mailing list<BR>
mpi-22@lists.mpi-forum.org<BR>
<A HREF="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22</A><BR>
<BR>
<BR>
_______________________________________________<BR>
mpi-22 mailing list<BR>
mpi-22@lists.mpi-forum.org<BR>
<A HREF="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22</A><BR>
</FONT>
</P>
</BODY>
</HTML>