This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [gomp] Challenges in Implementing OpenMP
Sebastian Pop wrote:
After having read some papers on STAPL, I found that one of the
targets of STAPL is OpenMP...
I appreciate your insights.
STAPL is a C++ solution. It does not address C or Fortran. One purpose
of OpenMP is to allow legacy code to be easily parallelized, and
wrapping everything in C++ is neither practical nor desirable. So in the
end, whether or not we implement OpenMP is not predicated on the needs
or desires of C++ programmers alone.
I'm *not* saying STAPL and Pivot are bad ideas; in fact, they coexist
quite nicely with OpenMP, such that the existence of one does not negate
the existence of the others.
In the case of STAPL one of the interfaces to
the compiler is OpenMP, clearly not very useful when you know that
STAPL computes the whole data dependence graph, but that all you can
transmit using OpenMP directives is whether loops are parallel or
not...
That is incorrect. OpenMP allows considerable detail in the
specification of parallel code regions, well beyond simple loop
parallelism and threading. The simplest application of OpenMP is to toss
a few "parallel for" directives into existing code; however, for more
complex tasks, OpenMP supports a powerful parallel region construct.
Up to prototyping tools you're right, but just thinking at instruction
level parallelism for which we're far from producing good code these
days, I'm sure that you didn't meant the last joke about reducing the
role of the compiler in the chain.
Good point, though work is being done to improve vectorization. In my
experience, class-level parallelization does not provide the same level
of optimization that is found in a compiler-level solution. (I note
Diego's message, which came in as I write this, speaks to much the same
effect.)
As a last remark, I would like to say that I'm not very enthusiastic
on having OpenMP in GCC, but this is a norm that, in my opinion, goes
in a right direction by allowing the programmer to control (in a very
unsafe way) the optimizers working downstairs.
I agree that OpenMP is imperfect, as are all technologies; but, as you
say, it is a "norm." Intel, IBM, Sun, Kai, SGI, Absoft, PGI, Lahey, and
others have implemented OpenMP in their compilers, with Pathscale and
Microsoft following suit in the near future. People have ported OpenMP
concepts to other languages, including Java. Recent RFPs from the U.S.
National Laboratories have considered OpenMP to be an essential
component of Fortran compilers.
So we forge ahead...
--
Scott Robert Ladd
site: http://www.coyotegulch.com
blog: http://chaoticcoyote.blogspot.com