[Mpi3-subsetting] MPI3: Proposal to remove PMPI-Requirement

[Jeff Squyres]

On Mar 7, 2008, at 10:20 AM, Bronis R. de Supinski wrote:

>> Additionally, I'm always wary of the term "real applications" -- what
>> a "real" application is to a US DOE lab is very different than what a
>> "real application" is to, say, someone in the oil and gas
>> industry.  :-)  The scale difference alone is enough to make the
>> latency gains by inlining select MPI functions important (meaning:  
>> non-
>> US-DOE-labs tend to run at [much] smaller scale; fabric latency may  
>> be
>> constrained to a single switch, and therefore *can* see benefit from
>> inlining).
>>
>> As I understand Rainer's proposal, the inlining aspects also
>> predicated on apps that enter production and are never changed.
>> Perhaps this is not a pattern used much at DOE labs, but it is a
>> pattern I see with many customers.
>
> I'm not going to get into a pissing match with you over what
> applications do what. You seem to almost be using "US DOE lab"
> pejoratively.

Not at all.  All I'm trying to say is that there are many different  
types of apps out there and many different usage scenarios.  What is  
appropriate for one kind of app run in one kind of scenario is not  
necessarily appropriate for another.

> What I can say without the slightest hesitation
> is that recompilation is often a significant barrier to tool
> acceptance for application users and those users are NOT
> limited to one site or even one type of site (yes, I know users
> who are not at "DOE labs").
>
> My opposition to changes that would force tools to require
> recompilation is borne from experience.

I agree with that point.  I, too, have some reservations against macro- 
based optimizations, but I would think that if someone *chooses* to  
use them, they they have implicitly agreed to forego some classes of  
tools and other kinds of features that would be incompatible with said  
optimizations.


-- 
Jeff Squyres
Cisco Systems