This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [gomp] Challenges in Implementing OpenMP


Scott Robert Ladd <coyote@coyotegulch.com> writes:

| Gabriel Dos Reis wrote:
| > 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 :-)
| 
| I was really hoping this wouldn't degenerate, like past discussions,
| into a debate over the merits of OpenMP and its syntax. I am more than
| willing to agree that there may be other (and even better)
| alternatives; however, the issue here is how best to implement OpenMP.


I'm not trying to reopen a new debate about the merits of OpenMP.  I'm
just saying my bias (as clearly marked in my message) about C++,
distributed and parallel computations and GCC/g++.  

| OpenMP is a widely-recognized industry standard implemented
| successfully by almost every commercial C, C++, and Fortran compiler
| (Microsoft is adding it to Visual C++ in the next major release.)
| There exists a significant body of OpenMP knowledge and code.
| 
| > 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/
| 
| I've worked a bit with STAPL, but it is a C++-only solution.

yeah, as I said, I was speaking about C++, not C not Fortran -- for
some reasons, those clear statements seem to have disappeared from
your reply.

| > There is another project initiated by Bjarne Stroustrup, which I know
| > more about (certainly more than STAPL :-)), called "The Pivot".
| 
| Again, it is C++ only.
| 
| > 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.
| 
| Your bias is a focus only on C++. I write 70% of my code in C++, so I
| sympathize. However, I also work with C and Fortran developers, and
| OpenMP is the solution in their domains.

I speak of C++ because you mention it in your message.  And I made it
clear from the outset of my message that I was not speaking for C nor
Fortran.  GCC is complex, and it currently fails to support C++.  If
it is going to add new complexity, I prefer see it to be something that
pays off for my colleagues and me (spending resources on it).  You're
speaking from your point of view.  I'm sharing mine.

My bottom line is, there is a large number of good frameworks for
parallel and distributed computations (in C++), there does not seem to
be a single that wins (which is one of the reasons why STAPL supports
not only one but many) and if GCC/g++ compiler is going to be
complexified to support a model, I see no particular reason why it
should pick that particular model and not others.  I rather see the
compiler gets "simpler".  Your mileage may vary and I understand that.
And the whole GCC team may have a different view -- if it happens to
agree on one. :-) 

Do not take my disagreement with the lines you outlined as my willing to
open a new debate.  Phil did a good job at reminding people about past
debates. 

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]