[Top][All Lists]
[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
- Re: [Gomp-discuss] GOMP Requirements v1.1, (continued)