Re: [gomp] Challenges in Implementing OpenMP

[Sebastian Pop <sebastian dot pop at cri dot ensmp dot fr>]

On Wed, Oct 13, 2004 at 04:16:34PM -0500, Gabriel Dos Reis wrote:
> 
> The view here at TAMU, is slightly different.  Instead of augmenting
> the language with CPP directives and whatnot that the programmer has
> to manually keep track of, we prefer to realy on higher level
> abstractions.  That is the approach taken and implemented by STAPL
> 
>   http://parasol.tamu.edu/compilers/research/STAPL/
> 

After having read some papers on STAPL, I found that one of the
targets of STAPL is OpenMP...

In my opinion for transforming the code into a parallel one, you must
gather some precious information that you don't want to just throw
away once you go down at the level of the compiler.  Reusing this
information in the compiler could avoid a costly computation, could
probably be more accurate than recomputing it at a lower level, and
finally could be useful for low level optimizations that are dependent
on the target architecture.

Last Tuesday I had the occasion to speak with Lawrence Rauchwerger
about STAPL.  I have asked him about how the data dependence
information is transmitted to the lower levels of the compiler.  This
is the same problem we're facing when trying to send the data
dependence information from GIMPLE to RTL, and I should say that this
issue is still open.  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...  When you don't consider the source to source approach, ie. the
STAPL compiler integrated to the code generator, the problem still
remains difficult: translate the DDG from the "higher-end" to the
"middle-end" then to the back-end.

I don't believe in the library doing all parallelization, because
generating calls to a threading library too early is just obfuscating
the code to be processed by the compiler.  This also is the case of
source to source OpenMP compilers.  Instead, I think that OpenMP
directives were designed to transmit information to the optimizers. I
don't believe either in the compiler doing all the analysis and all
the optimizations alone, because some information cannot be determined
so easily down in the middle end, and for this purpose STAPL provides
high level constructs that avoids the programmer to stick his fingers
on the low level details.  I find the ideas behind STAPL very exciting
because it allows intuitive description of the parallelism without
extending the syntax of the C++ language, as you said, you don't have
to teach the compiler the semantics of the new constructs that you put
in the library.  But probably this is the whole bad point about all
this approach, ie. the reason it is so difficult to reuse the high
level information down in the compiler...

> There is another project initiated by Bjarne Stroustrup, which I know
> more about (certainly more than STAPL :-)), called "The Pivot".
> 
> The Pivot is a general framework for static analysis and
> transformations  of C++ programs.  One of the main goal is to provide
> direct support for distributed and parallel computations in C++.
> We believe that support through library is much more scalable, more
> portable, more general than support through CPP and language
> extensions that would require most of compiler rewrite.
> 
> The Pivot relies on a (potentially standard) internal program
> representation.  Here is a 30-min slides overview of the 
> "The Pivot"/IPR structure.
> 
>    http://www-unix.mcs.anl.gov/workshops/DSLOpt/Talks/DosReis.pdf
> 
> So, you can see my bias:  Keep the compiler simple, delegate
> domain-specific semantics to domain-specific tools;  Keep the
> abstraction high level, and delegate byte fiddling to the computer
> scientists and equations to physisists/numericists.
> 
> Keeping the compiler simple also make it easier to figure out bugs and
> fix them.  Just take GCC as an example :-)

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.

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.

Sebastian