gomp-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gomp-discuss] Welcome!


From: Pop Sébastian
Subject: Re: [Gomp-discuss] Welcome!
Date: Wed, 18 Dec 2002 02:01:06 +0100
User-agent: Mutt/1.3.28i

Hi everybody,

On Tue, Dec 17, 2002 at 10:42:17PM +0000, Biagio Lucini wrote:
> 
> OK, know for the discussion. Just for a start, I suggest the following
> topic. OpenMP has Fortran and C/C++ specifications. A naive approach for a
> compiler would be to parse the OpenMP directives either in Fortran or in
> C++ and to translate them onto a threaded program in the original
> language. 

OMP was designed to be a "language of directives".  The set of OMP directives
serves as an interface between the programmer and the compiler.  The compiler
can choose to follow these directions provided by the programmer, or just 
ignore 
them (as is the case of GCC today).  This is what Philippe Gerner calls in his 
PhD. thesis the contract between the programmer and the compiler.  

Concretely how I see all this is that the compiler translate all the
directives firstable into attributes/nodes attached to the corresponding 
tree node, then following the situation the compiler could decide to respect 
the contract or just leave trees as they are. 

> If I interpret correctly his point, Diego suggests (and
> apparently AFAIK also Open64 uses the same approach) to translate the
> source into an intermediate language and then to process that. What are
> the advantages of this second approach? 
> 
We just need some tree nodes in GENERIC tree representation for objects like 
threads
(I'm not sure, but I think Java already uses them ...)

> 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?


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?...)

This was just a 2 am. dream. Now I'm awake to go sleep  :-)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]