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