[Mpi-22] Ticket #46: Add const Keywordto the Cbindings-implementation

[Erez Haba]

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