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

Geva, Robert robert.geva at intel.com
Sat Jun 29 17:29:40 CEST 2013


Olivier is obviously right - solutions that require the compiler for their implementation are not in themselves extensible by the user.
In WG21 SG1 these were compared to other features where we have both structured and unstructured mechanisms, such as data allocation, alongside each other, and most programmers are clear about when to use which.

I also made the same observation as Clark: there is a majority that supports the language based solution which requires compiler implementation. Once we pass the introductory stage in CPLEX, we can repeat some of the presentation from SG1. On the tasking side, there was a presentation on the benefit to the programmer from compiler based implementation. On the SIMD side, where the vector level parallelism is implemented by generating different instructions, the compiler has to generate them. To Olivier's point, an extensible solution on top of the keyword based solution can also be added, once the keyword based solution is in place.

Another point that was made in SG1 is that both task and vector level parallelisms modify the order of evaluation. The order of evaluation, like the memory model, is at the core of the language. Therefore, a programming construct that allows a new order of evaluation should be standardized within the language rather "sneak in behind the back". There was a majority agreement on this point as well, but this was not considered actionable in itself: in order to standardize the order of evaluation, the committee felts that that order needs to be presented with a concrete way for the programmer to use it, so that part of the proposal should happen next.

Robert. 

-----Original Message-----
From: cplex-bounces at open-std.org [mailto:cplex-bounces at open-std.org] On Behalf Of Olivier Giroux
Sent: Friday, June 28, 2013 8:57 PM
To: Nelson, Clark; Matthew Markland; cplex at open-std.org
Subject: Re: [Cplex] Keywords, compliance, and a parallel UNCOL.

The main issue some see with language extensions is that they are not extendable themselves, by users.  Everyone is going to want/need to tweak this and few are compiler engineers.  Some will want to plug in significantly different implementations of their own.

There were some really good points made by Pablo at the last meeting, about the weak points of library solutions in this space.  The question now is: what is the more general language feature that will make the library extension great?  That feature could make all of C++ better.

Lastly there is much to like in Cilk because it's a good design.  You're getting very few arguments about the semantics.  More people would be happy with a Cilk library, even the design Pablo showed and disliked.

Olivier

On 6/28/13 4:01 PM, "Nelson, Clark" <clark.nelson at intel.com> wrote:

>There are a few people in the C++ committee who are strongly opposed to 
>requiring support for parallelism in the compiler, but the clear 
>majority (at least in the parallelism study group) are at least weakly 
>in favor of it. Personally, I have no idea what's eventually going to 
>happen in WG21.

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain confidential information.  Any unauthorized review, use, disclosure or distribution is prohibited.  If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
_______________________________________________
Cplex mailing list
Cplex at open-std.org
http://www.open-std.org/mailman/listinfo/cplex


More information about the Cplex mailing list