This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [gomp] Challenges in Implementing OpenMP
- From: Gabriel Dos Reis <gdr at cs dot tamu dot edu>
- To: Scott Robert Ladd <coyote at coyotegulch dot com>
- Cc: gcc mailing list <gcc at gcc dot gnu dot org>
- Date: 13 Oct 2004 16:16:34 -0500
- Subject: Re: [gomp] Challenges in Implementing OpenMP
- Organization: Texas A&M University, Department of Computer Science
- References: <416D5F62.1040508@coyotegulch.com>
Scott Robert Ladd <coyote@coyotegulch.com> writes:
[ complex result of code transformation ]
| Essentially, OpenMP restructures the original code. The above example
| is incredibly simple, and only touches the surface of OpenMP's
| complexities. For example, OpenMP directives often contain clauses
| that define variable sharing among threads.
|
| My feeling is that OpenMP processing should take place in the language
| parser. Given the differences in the parsers for C and C++, this looks
| to require separate modifications to those compilers.
I apologize in advance for what might look like an unsolicited ad.
However, the topic raised by Scott concerns GCC, C++ and a domain I'm
interested in. All three reasons I feel concerned :-)
[ Speaking as someone interested in parallel and distributed computations
in C++ (I don't speak for C or Fortran). ]
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/
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 :-)
-- Gaby