[Cplex] Integrating OpenMP and Cilk into C++

Nelson, Clark clark.nelson at intel.com
Sat Jun 22 00:10:35 CEST 2013


> In my opinion, if we do not specify a scheduler interface as part of this
> effort, we will have done nothing worth doing.  Neither Cilk nor OpenMP are
> useful without a runtime managing concurrency, scheduling work and (in some
> fashion) allowing the user to control concurrency.  Either one can be used
> without one, but then all that's left is an overly verbose serial program
> (well, with better than average SIMD usage, but I digress).  I am personally
> not interested in specifying a parallel language extension with no standard
> way to control its behavior.

I'm sure you're right -- from your perspective. I absolutely believe that you,
personally, would benefit in no way.

However, I'm pretty confident that there are quite a few less sophisticated
programmers in the world who would benefit considerably from having an
easier way to write a parallel program than by using pthreads, and an easier
way of writing a scalable, composable parallel program than by using OpenMP;
and they would benefit even more if that way were in some way standard.

BTW, when you talk about a "standard way to control its behavior", do you mean
"control" in any broader sense than would be covered by "tune"?

> In that sense I believe we need to specify *something* as a standard
> scheduler interface. The question at hand is not necessarily whether we
> should attempt to make *a single scheduler* which is perfect for all
> occasions, a nigh impossible task on the best of days, but rather a standard
> interface and mechanism for composing schedulers within an application,
> probably a standard library interface of some sort.  In that fashion we
> allow users and runtime implementers to define schedulers which fit their
> needs, but still incorporate into the standard system.

I wholeheartedly support this idea. But I feel it's a separate and deeper
topic (and in a lot of ways more interesting :-) than the simple ability to
express what I'll call opportunistic parallelism, as in a program that can
take advantage of more than one processor, which can still be useful even if
it isn't tuned to within an inch of its life.

Please note that I *didn't* say that this separate and deeper topic should
be given lower priority than the other.

Clark


More information about the Cplex mailing list