[Cplex] Cplex: suggested topics for discussion on the next teleconf.

Tom Scogland tom at scogland.com
Wed Jun 19 10:43:53 CEST 2013


The way Herb put his arguments brings up an interesting point.  During the
call there was a great deal of discussion with regards to the scope of our
mandate, and whether this should be a language independent or C-only
proposal, maybe both are true.

Specifically I'm referring to the statement "IMO we cannot live with a
long-term requirement that applications use multiple schedulers."

I agree with that statement, and would further argue that it applies across
more disparate languages than just C and C++.  It does not say anything
about the actual parallel extension or specification however, just the
runtime system.  The current merged proposal explores extensions for the
expression of parallelism which are completely dependent on a runtime
system to run efficiently, or at all in a concurrent context.  Even
so, following
from its Cilk roots, the proposal does not specify anything about that
runtime system beyond that it will not violate the guarantees of the
language level constructs.

If the interface of the runtime scheduler is specified such that it can be
language independent, with a common design and layout for tasks or ranges
of tasks, their corresponding data, dependencies and scheduler controls,
that should be sufficient to allow for interoperability.  Note that I said
the runtime scheduler, by which I mean concurrency manager and task
scheduler, not parallel language extension.

Then a language specific syntax can be developed for C, C++, Ada, or any
other language that could submit tasks.  Perhaps they could even be used to
implement alternative runtime schedulers as well.  In the end, this gives
us a C specific extension for parallelism that could be composed with
similar systems in other languages, libraries and whatever else.

Clearly this is just my thought process, but the idea of designing what we
need in two components, a scheduler API and a language extension, seems to
solve several of the problems that have been nagging at me.  I think it
would also provide a nice separation between the parallel specification and
tuning/concurrency control as Clark suggested. The default could be to only
use the parallel language extension, simply using whatever scheduler is the
language/compiler/standard library default, allowing the system to do
whatever it wants. But, if the user is so inclined, an alternative
scheduler or control points on the default one could be tuned through an
additional interface.

-- 
-Tom Scogland
http://tom.scogland.com
"A little knowledge is a dangerous thing.
 So is a lot."
-Albert Einstein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/cplex/attachments/20130619/2b8a4859/attachment.html 


More information about the Cplex mailing list