[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gomp-discuss] GOMP Requirements v1.1
From: |
Ioannis E. Venetis |
Subject: |
Re: [Gomp-discuss] GOMP Requirements v1.1 |
Date: |
Fri, 12 Nov 2004 14:52:20 +0200 |
User-agent: |
Mozilla Thunderbird 0.9 (Windows/20041103) |
Dear Scott,
This document is really very nice and I agree mostly with it. But, of
course, I have some concerns, which can be tracked down to the last
paragraph of the document:
"GOMP will use the threading model specified by the –enable-thread=xxx
configuration option."
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.
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).
This means that very generic OpenMP helper functions will be used, like
_OMP_MasterFunction, _OMP_GetNextChunk, etc. These functions implement a
master-slave parallel programming paradigm, as required by OpenMP, and
will use more specific function calls according to the threading model
used, like pthreads_create/join if POSIX threads are to be used.
Here is where my proposal starts to make sense. There are many threading
libraries out there that implement a master-slave parallel programming
paradigm and, by the way, I have been working for long on such a
library, in the context of a project, which has given me some experience
on these problems. We had modified a compiler to produce code that used
the API of our library. The first versions of the compiler injected
directly the whole parallel code, but we moved to a scheme that is
almost the same as the one proposed in Ross' document. 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.
Allowing to change the threading library that is linked in, will allow a
great amount of (mostly research?) projects that implement such
libraries to use GCC as an OpenMP compiler. The only need will be to
implement the OpenMP helper functions using the API of the specific
library, which I repeat should be trivial in most of these libraries,
and link with the new version of libgomp. This might also help GOMP to
be adopted by a much bigger community, because from my experience, the
most difficult part in these projects is to have a compiler that
generates code for your library, so that you can use directly big
applications and not have to write them from scratch.
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.
Some other minor corrections in the document:
1) In the last paragraph under "Justification":
The phrase "will provide a simplified syntax tools" should be either
"will provide simplified syntax tools" or "will provide a simplified
syntax tool"
2) In the second paragraph under "Effects":
The phrase "All effort will be made to unify these modification to limit
duplication of effort." was a bit difficult to me to understand (I had
to read it 3 times :-). Maybe we could rephrase it as "Special care will
be taken to make these modifications as generic as possible, in order to
avoid duplication of effort."
3) In the third paragraph under "Effects":
Should the first word (Change) be "Changes"?
4) In the fifth paragraph under "Goals":
"GOMP will be well documented, such the other developers will understand
the how OpenMP affects GCC" should be "GOMP will be well documented,
such that other developers will understand how OpenMP affects GCC"
I apologize for the length of the document and I hope that the
discussion will continue and some good solutions will emerge.
Ioannis E. Venetis
Scott Robert Ladd wrote:
Hello,
I've posted the GOMP Requirements document for public review.
http://www.coyotegulch.com/gomp/gomp_requirements.html
Or, if you prefer PDF format:
http://www.coyotegulch.com/gomp/gomp_requirements.pdf
This document has also been announced in several newsgroups and other
forums, where users and developers may have an interest in this project.
All considered comments are welcome.
..Scott