[Cplex] Integrating OpenMP and Cilk into C++

Pablo Halpern lwg at halpernwightsoftware.com
Fri Jun 21 23:21:59 CEST 2013

This seems like a good opportunity for me to get educated and, from what 
I've seen, I'm not alone in needing to be educated in this way.  I'm 
wondering how static scheduling can be composable.  Consider the 
following (avoiding any specific syntax for fear that I'll get it wrong):

void f() {
     parallel_statically_scheduled_loop (int i = 0; i < 1000; ++i)

void g(int i) {
     parallel_statically_scheduled_loop (int j = 0; j < 1000; ++j)
         compute(i, j);

If there are N cores available, how do you avoid having N-squared 
threads in the inner loop?

Anticipating that you might tell me that the scheduler detects that 
there are no more threads available, and therefore run the inner loop 
serially, I'll ask a follow-up question: do any implementations actually 
do this?  If not, why not? (It's been a well-known problem for a long 
time, so its surprising to me that no implementation would have fixed 
it, if that's the right thing to do.)

I empathize with the annoyance of people making incorrect assumptions 
about a model they don't understand (they do it with Cilk all the time), 
so I'll try to refrain from doing that with OpenMP in the future.


On 06/21/2013 04:26 PM, Bronis R. de Supinski wrote:
> Pablo:
> Re:
>> There is no need to get defensive.  I am not attacking OpenMP.
>> However, it is well known that widely-used OpenMP features,
>> particularly static scheduling, do not compose well with libraries
>> that also use parallelism. If the author of a piece of code does not
>> know whether that code might be called in a parallel context, then he
>> cannot use parallelism without risking exponential oversubscription.
>> (I have seen this happen, often). If run on a desktop or mobile system
>> rather than a dedicated HPC system, static scheduling creates load
>> imbalances that hurt performance.
> While I will agree that composability with other parallelism
> models is a weakness of OpenMP, composability with itself is
> not. The issue that you raise is not one of the model or the
> specification but rather one of quality of implementation.
> Omitting static scheduling would be a mistake. Many, many
> situations are well suited to it and it is a natural, low
> overhead concept.
> Bronis

More information about the Cplex mailing list