Re: [Gomp-discuss] GOMP Requirements v1.1

[Scott Robert Ladd]

Ioannis E. Venetis wrote:
> Although I agree that this should be the default behaviour, I would be 
> very happy to have a way to change this behaviour during linking of an 
> OpenMP program.

Commercial compilers impose a threading model without providing 
alternatives. OdinMP, if memory serves, allows specification of a 
threading model at compile time.

I'm told that the gcj Java compiler uses the model defined by 
--enable-threads=xxx during configuration. I think OpenMP will have a 
better chance of success if it follows that same pattern.

> It is my understanding that development will proceed more or less along 
> the lines of the document that Ross Towle has posted some time ago 
> (http://lists.gnu.org/archive/html/gomp-discuss/2004-08/msg00000.html). 

Ross' document is a good piece of work, but it is not a complete design 
document. We have several issues that need to be seriously considered 
before we know all the details of hos this is going to work. In many 
ways, I think we've gotten that cart before the horse; we've implemented 
a support library with questionable copyright legalities, and we have 
designs before we even define what all the requirements are.

I'm not a stick in the mud about documentation, but I do believe we've 
rushed ahead on some issues without fully discussing the consequences. 
This proposed requirements document, simple as it is, has already raised 
issues that people have not previously considered.

> Changing the 
> library to support this new scheme was quite easy and I expect that 
> other libraries could be changed quite easily too, to support such a 
> scheme.

I'm not objecting to the concept, but I have seen resistance to it in 
the mainstream GCC community (mostly from people who erroneously believe 
OpenMP == Java threads).

> I have also seen some concerns about the statement "in some cases, how 
> code is reorganized depends on the threading model in use". I tend to 
> agree with Ross on this matter, that the correct approach is to use only 
> generic functions and implement them in a library. From my experience, I 
> am convinced that most (if not all) performance issues with 
> multithreaded applications can be effectively solved in the threading 
> library.

The perspective on this depends on your use of OpenMP. As Lars pointed 
out, using architecture-specific techniques is an optimization necessary 
for optimal performance. For production work, people are going to want 
to produce optimal parallel code.

A wild idea: Perhaps we need to consider additional tuning options, such 
as "-fopenmp=generic" for link-time selection of a threading model, and 
"-fopenmp=native" for platform-specific code? Such a concept increases 
complexity in exchange for satisfying more people.

The real question is: Does GCC care about being competitive in terms of 
performance? If intellectual freedom is the only goal, then we can by 
all means approach this from a generic perspective. If we want a 
compiler than is a practical alternative to commercial products, we need 
to concern ourselves with performance issues.

--
Scott Robert Ladd
site: http://www.coyotegulch.com
blog: http://chaoticcoyote.blogspot.com