Cilk/Cilk+ is not the answer, despite years of Intel promoting it and open-sourcing it. Intel has touted many other || technologies in the past: OpenMP, TBB, and now Cilk+. These are all useful tools, but none of them is the way of boldly moving forward with || programming, IMHO. I believe the easier || programming will come from actors, CSPs, channels and other technologies that provide safe concurrency as the working basis.
Cilk/Cilk+ is not the answer, despite years of Intel promoting it and open-sourcing it.
Intel removed the features that gave Cilk a reason to exist: inlets and aborts. They're useful for (partially) parallelizing hard-to-parallelize problems that don't fit well into the other frameworks like OpenMP etc. Why did they remove them? I'm guessing because they were difficult to do well, and the algorithms that need them don't present such nice linear scaling graphs for marketing slides.
However, without those features, Cilk just doesn't distinguish itself enough from OpenCL, OpenMP etc. Parallelizing easy to parallelize problems isn't the problem, it's the others we need help in dealing with!
The poster childs/demos for the original Cilk were parallelized chessprograms, some of which did quite well in real tournaments. It's a very well studied area that exhibits a lot of parallelism, but not in a form that's easy to extract (hence there are no competitive ones using OpenMP, GPUs etc). Cilk was able to do it, a major achievement. But you can't even construct those in Intel's crippled Cilk version any more. Well, not any that would be competitive, anyway, which is the point to begin with.
If your solution only solves the easy problems others have already solved, what exactly is your right of existence?
True, Concurrency is not Parallelism [http://concur.rspace.googlecode.com/hg/talk/concur.html], but sometimes all you need is parallel execution of a single algorithm, and you need a set of primitives that succinctly and efficiently express that parallelism... not to mention integrated access to SIMD and GPUs, where only parallelism need apply. I'd say there needs to be both a high level "break your app's work into a heterogeneous set of processes" API, like CSP, and a low level "run an algorithm on this array really fast" API.
Did you mean CPS instead of CSP? Not trying to be snarky/pedantic, just making sure there isn't some acronym in this space I am unfamiliar with (not entirely unlikely :)).
