[Cplex] Parallel Manager and More
clark.nelson at intel.com
Thu Jun 20 22:26:42 CEST 2013
I have three things to say about the general topic of tunable and
interoperable run-time support for parallel programming.
(1) I believe it's very important.
(2) I have enough ignorance about it to sell wholesale, so I'm virtually
certain that I have nothing of any technical substance to contribute
(3) I suspect that it would make more sense to work on it in an SC22
context, rather than a WG14 context. (It's possible that my personal
ignorance is contributing to my impression that it should be done somewhere
else, but the topic certainly transcends C and C++.)
> -----Original Message-----
> From: cplex-bounces at open-std.org [mailto:cplex-bounces at open-
> std.org] On Behalf Of Stephen Michell
> Sent: Thursday, June 20, 2013 11:33 AM
> To: cplex at open-std.org
> Subject: [Cplex] Parallel Manager and More
> This took a while to respond because I in Europe at stds meetings
> with sometimes marginal email access.
> I want to address Daryl's comments about parallelism manager, etc.
> First a qualification: I would like us to be careful not to call
> it the "Ada model". Right now it is a model that the 3 of us
> (Miguel, Brad and myself) have
> presented unofficially to Ada Europe and more officially to the
> 16th International Real Time Ada Workshop (IRTAW 16). It certainly
> generated some interest,
> but we also took some cannon fire across our bows. I'll discuss
> some of the issues later.
> We submitted the Ada Europe paper end November, and our thinking
> evolved after that first paper. In particular, Parallelism Manager
> and Worker Task (thread
> in C/C++/POSIX) Pool Manager. The job of the Parallelism Manager
> is to manage the application of the concurrency for each
> Parallelism OPportunity (POP).
> The Parallelism Manager has no Tasks to schedule on his own. This
> is very much along the lines of Darryl's separate parallelism
> The Worker Task Pool Manager manages a single collection of Tasks
> that will be the worker tasks that execute the Strands for as many
> POPs as need the
> service. There can be a single Worker Task Pool Manager or there
> can be more than one: the Tasks in a managed pool of Tasks can be
> created dynamically as
> needed, can be fixed, or can be one per cpu.
> The point of the above is that there can be multiple pools of
> tasks. This is particularly useful when preemption and priorities
> are involved. If a Task reaches a
> POP and invokes the Parallelism Manager associated with that POP,
> it needs worker tasks at the same priority. One way to do this is
> to change the priority of
> each Worker as it collecting work. Another way is to have pools of
> workers at each priority.
> Someone complained about the single queue. In our model, there
> will be 1 queue for each pool of ready worker tasks. There is no
> efficiency issue because it
> truly is FIFO,
> I have a few things to say about blocking. Originally in our
> model, we followed the CILK plus model and were permitting Strands
> to block. One shot across our
> bow was that IRTAW 16 abhors blocking in such cases.We note,
> however, that some parallel algorithms do not work without
> blocking (for instance when you
> do a parallel->serial->parallel and it is important that the 2
> parallel pieces work on the same data). Our conclusion is that
> Strand blocking is one of those
> issues that needs a configuration setting.
> Note that we do not actually say that the workers will be tasks,
> or how they are scheduled, unless the programmer takes charge and
> binds his own parallelism
> manager and worker task pool manager(s) to the program. Until then
> the compiler and runtime is free to do as necessary.
> Hope that helped.
More information about the Cplex