Re: [Gomp-discuss] Somethings to think about ....

[Steven Bosscher]

Hi Lars, all,


Op ma 10-03-2003, om 13:44 schreef Lars Segerlund:
>   I have also been looking at the linux support for MP, and NUMA ( which 
> was added lately ), and linux does support affinity and NUMA in the 
> latest kernels, however to take maximum advantage of this it would be 
> quite resonable to do a native port to linux ( using clone instead of 
> any thread library ), and only implement the synchronization element's 
> needed by openMP.

I think our goal should be to make GCC concurrency-aware and use it for
OpenMP with threads as a first application.  Everything else
(autoparallelization, NUMA-awareness, grid computing, the construction
of HAL, what else?) is beyond the scope of this project.

If you want to make stuff linux-specific, you'd have to stuff it down
the throats of the GCC community with force and violence to make them
accept your contribution and like it.

Besides, load balancing, scheduler affinity and other low-level SMP/NUMA
stuff is the kind of stuff that a kernels is responsible for.  OpenMP is
not designed for such purpose.

(You can distribute tasks over clusters of CPUs with HPF2 (DISTRIBUTE,
BLOCK, etc.), that gives you some control of how your job will run on a
NUMA machine.  But it's not very portable and as a developer you need to
know all the ins and outs of the machine you're targeting.  I suppose
this explains why I've seen only a few HPF applications that use this
feature...)


>   Still the first thing to do is to get openMP running with a threading 
> library, and perhaps ( if smp safe ) a semaphore library.
> 
>   As for the tasks ahead, I think it's not to hard to use the framework 
> in the paper to target the GENERIC tree's ( which is the most resonable 
> form to target IMHO ). The algoritms for an rather good implementation 
> seem's to all be there, and the nice part is that if we extend the 
> pragma handling and add a -fgomp to gcc, we should be able to leave most 
> of the regulat stuff in place.

I would prefer -fopenmp :-)


>   I do however have a question, I know gcc does support barriers, but to 
> what extent and in what context ?

What do you mean with "GCC supports barriers"?

The only barriers I know of in GCC are BARRIER insns in RTL.  In that
context, a BARRIER basically is just the marker of the end of a code
block (e.g. after an unconditional jump_insn).  In other words, it
states: "Control flow ends before this".  It is used for code alignment
(i.e. the insn following the BARRIER can be aligned) among other things.

This has nothing to do with barriers they talk about in the OpenMP
specs; that one synchronizes threads.


> As far as I understand it it supports 
> barriers which prevents sections of code to be handled together, ( tus 
> enforcing separate optimization ). I'm still looking, but does anybody 
> know if this is correct ?

Well, barrier really are just markers for places where there is one and
only one out-edge in the control flow graph.  That does not necessarily
imply that all the optimizers stop there.

For example, after expanding trees to RTL, you'll see that the dump file
is littered with BARRIERs all over, but after some basic flow graph
optimizations (jump!), most of them are gone.  And if that single edge
before the barrier is a back-edge, the loop optimizers use them to
identify loops.  And crossjumping is all-barriers?  In these case,
barriers _allow_ the compiler to identify optimization opportunities!


>   I thought that we might as well start documenting what we want to do 
> with gcc, the trees and what we have to modify.

Do you have a plan we can discuss on some mailing list?

Greetz
Steven