[gomp] Challenges in Implementing OpenMP

[Scott Robert Ladd]

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