[Cplex] Keywords, compliance, and a parallel UNCOL.

Darryl Gove darryl.gove at oracle.com
Sat Jun 29 00:03:14 CEST 2013

On 6/28/2013 2:33 PM, Matthew Markland wrote:
> I'm just going to plunge in here; my experience in the standardization process is limited so my comments may be naïve. There are a number of issues here I wanted to get out for discussion.
> I realize that the group is focused on C, but if C++ buy-in is wanted, from discussions I've seen, I'm pretty sure that keywords are not going work out. Would there be any interest in moving towards something similar to the C++ attribute syntax? For example:
> [[spawn]] for(int i = 0; i < 32; i++) {...
> I suppose an implementation could even support multiple versions of spawn:
> [[cilk::spawn]]
> [[offload::spawn]]

At this point I think we're just wrestling the concepts, and the syntax 
will follow that. But this could be one approach.

> My compliance question goes along with the syntax. Assuming these features go into the standard, should they be marked optional for compliance? Is there any feeling that vendors would choose not to adopt a standard if it requires these constructs? If they aren't required, I'm thinking keywords again might not be the best implementation. An implementation could be free to ignore attributes they don't support.

The plan is for a techical report that eventually migrates into the 
standard. At this point we don't know whether they would be mandatory or 

> Finally, the UNCOL comment:  I don't disagree with the idea that a common scheduling substrate/runtime is needed, but I'm worried about falling into the trap of trying to create the impossible. Given the different requirements we've already seen voiced between "regular" and "HPC" users desires for control, I'm concerned that there would be the need for too many knobs to try to support all these different visions of parallelism. So, is the focus here just on a common substrate that works with the Cilk and OpenMP models, or is it define a substrate upon which someone could build their own vision of parallelism which would then compose with C, OpenMP, Cilk, etc?

The original proposals were taking existing Cilk and OpenMP language 
extensions and trying to build language extensions around those.

Providing a runtime that Cilk and OpenMP could be built on top of was 
not the objective.

That said, I think the discussion on this alias has indicated that we 
have two factors, the language extensions, and the runtime support.

> As a follow on to the above, is the focus here going to be simply shared memory parallelism or will spawn be allowed to off-load work to an accelerator? Data movement becomes critical if that is allowed, and would probably add to the complexity of this base runtime.

We arrived here from OpenMP and Cilk, so we're in the shared memory 
domain. However, we also have some proposals around simd, and simd is a 
small step from GPUs.

Personally, I don't think we want to rule anything out at this stage, 
but equally well we don't want to stall because we try to include 



> Thanks!
> Matt
> ----
> Matthew Markland
> Cray, Inc.
> Compiler Front-End and Libraries
> C/C++ Front-End
> markland at cray.com 651-605-9186
> _______________________________________________
> Cplex mailing list
> Cplex at open-std.org
> http://www.open-std.org/mailman/listinfo/cplex

More information about the Cplex mailing list