[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gomp-discuss] GOMP Requirements v1.1
From: |
Scott Robert Ladd |
Subject: |
Re: [Gomp-discuss] GOMP Requirements v1.1 |
Date: |
Fri, 12 Nov 2004 09:35:50 -0500 |
User-agent: |
Mozilla Thunderbird 0.9 (X11/20041107) |
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