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

[Terry Dontje]

I am not Jeff and I do not play him on tv but I felt the need to 
interject my 2 cents.

Erez Haba 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?
>
>   
Possibly but it definitely is biased IMO.
> 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.
>
>   
Isn't MSMPI based on MPICH?  If so how much of the previous work done to 
support const did you leverage or did you truly reinvent the same wheel 
MPICH developers did?  I guess I find it pretty amazing the applying 
10,000 lines of changes and then validating them took you 2.5 hours.
> 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).
>
>
>   
Do the ANL tests and any others really test const-ness without changes.  
Or are you saying the ANL tests already do explicit testing of 
const-ness on the right parameters? 
> With this information that I have already provided before, I don't understand your claims; unless you think that they are biased and unreliable.
>
>   
I would say your information is a useful datapoint but I am curious if 
what you did really was the full conversion of your MPI implementation 
to handle this change.
> Hence this ticket completely meets MPI 2.2 requirements in scope and backward compatibility.
>
>   
For MPICH based implementations I agree it does.  For Open MPI I think 
it is still questionable.  I guess I am still interested in the 
reasoning why shoving this ticket into 2.2 is such a high priority?

--td
> 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.
>
>