Re: [Gomp-discuss] Welcome!

[Pop Sébastian]

On Wed, Dec 18, 2002 at 09:19:50AM +0000, Biagio Lucini wrote:
> > This is what Philippe Gerner calls in his PhD. thesis the contract
> > between the programmer and the compiler. 
> > 
> 
> Is this thesis available somewhere 

http://icps.u-strasbg.fr/~gerner/these.ps.gz
but it's in french...

> and does it contain useful
> documentation for non expert like me on nodes, trees etc? 
It's much more about the semantics of a directive language: what is the 
official semantics (the OMP standard paper) and what is the effective 
semantics (the one implemented by a compiler).  

> I don't have a
> background in Computer Science, I'm an humble physicist, so some more
> basic documentation will be very welcome. Any suggestion?
> 

I've started with the papers comming form McGill university.  They 
used an early version of GCC and extended it into an optimizer/parallelizer
compiler.  They explain very well the structure of their compiler, as well
I remember having read a paper about the tree structure that is close enough
to the GCC ASTs.

All their work (research reports and publications) is available at:
http://www-acaps.cs.mcgill.ca/info/McCAT/McCAT.html
but their compiler is not available... (maybe I've not searched enough?)

Another research group on compilers where you can find lots of documentation 
is the SUIF project (Stanford University).

> 
> > > And, by the way, do you know a suitable candidate threading library that
> > > we could use for threading the application?
> > > 
> > we could just use POSIX threads?
> > 
> 
> That's what I was thinking of doing. Any other choice probably would be
> unportable. The only thing that put me slightly off is that POSIX threads
> are not exactly the easiest thread library on earth...
> 
and we have some portability issues with windows I think...

> 
> > Maybe this is only science fiction for the moment, but here is what I think 
> > about all this...
> > 
> > OMP was designed in order to increase the interactivity between the
> > programmer and the compiler.  Now what happens if we allow the
> > programmer to deal directly with all the intermediate representations of
> > the compiler? 
> > 
> > For example one would like to work at the function level, then it could
> > study directly the call graph, and guide the compiler to optimize only
> > some functions instead of applying the derecursivation on all the
> > functions, we could allow the programmer to specifically optimize only
> > those functions he expects.
> > 
> > We play the same game when we deal with parallelization directives: 
> > instead of just writing directives in ASCII I think that the programmer
> > would prefer the direct interaction with the compiler.  This constant 
> > feedback 
> > could be efficiently used by the compiler in order to propose more advanced 
> > optimizations based on the informations the programmer is able to provide...
> > (and what happens if the programmer provides false informations?...)
> > 
> 
> It's a good idea, but how would be practicable in fact? In my experience,
> many programmers don't know too much about optimisation and similar
> things, and they are pretty happy with whatever the compiler does.

You're right, but what about directive languages?
For using parallelisation directives one should have strong knowledge about 
data dependence analysis.  This implies that one should learn how to use 
such a dangerous tool before exploiting it.  Thus I don't worry too much, 
since all we expose to the programmer is a little more interaction.  I think
that the programmer will know how to take advantage of such a tool.

> Could
> we use information given by a profiler as a feedback input?
> 
Certainly, yes.