gomp-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Lars Segerlund
Subject: Re: [Gomp-discuss] GOMP Requirements v1.1
Date: Mon, 15 Nov 2004 10:53:33 +0100

 I think we should concentrate on -fopenmp=POSIX for now.

 / Lars Segerlund.


On Fri, 12 Nov 2004 09:35:50 -0500
Scott Robert Ladd <address@hidden> wrote:

> 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
> 
> 
> _______________________________________________
> Gomp-discuss mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/gomp-discuss




reply via email to

[Prev in Thread] Current Thread [Next in Thread]