Re: [Gomp-discuss] The primitives

[Lars Segerlund]

 It's more complicated :-) ... check out the dynamic extent example in 
the spec ( first 10 pages or so ), the issue is with calls taken. But I 
think you are quite right, it's extraordinarily implementation friendly 
for a standard.

 The reason I thought we wouldn't need a lib is that I thought we could 
generate native calls to the thread library of choice, since most 
mechanisms we need are supported in fx. linux threads.

 I have since silently given in to the notion of a lib ( only to come 
back with vengence later ha ha ha ... ;-)  )

 Also note that generally you want to run a higher number of threads 
that you have CPU's, on an NUMA machine a number of 2-4 threads/cpu is 
usually a good choice, sometimes you need a larger number, this in order 
to keep the cpu busy if you have page faults or contetntion in parts of 
the code.

 So I'm all for Scott's suggestion of handling

#pragma omp parallel

 First since this is THE primitive.

 / Lars

Biagio Lucini wrote:
> I've missed so much of the "real time" discussion today that I don't know
> exactly who I should quote here - sorry!
>
> I agree with Scott that perhaps the best thing to do for a start is to get
> the simplest program work. However, I am not sure if I agree on the
> observation that we don't need the library routines. One thing we will
> need at some point is some function that will get the number of the CPU's
> available to the system: the correct execution of the "hello" example
> depend on the fact that the compiler must know how many CPU's the system
> contains. 
>
> For the common set of primitives, it seems to me that everything reduces
> to a fork with a more-or-less complicated control instruction. E.g.
>
> #pragma omp parallel -> fork n-1 processes if n is the number of the CPU
> (the master process is still there)
>
> #pragma omp for -> on each forked process manipulate according to the
> clauses the index of the loop
>
> #pragma omp sections -> whatch how to fork the section directives
>
> #pragma omp section -> put it just in one thread (it does not matter which
> one)
>
> #pragma omp master -> this is not forked, must be executed just on the
> master thread
>
> Perhaps we tree is simpler than it seems at first sight or am I too naive
> and indeducated in CS?
>
> Then, a separate chapter are the synchronisation statements (barrier,
> critical, flush), which probably require "wait" and "lock".
>
> Biagio
>
>
>
> _______________________________________________
> Gomp-discuss mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/gomp-discuss