Comment by cabacon | Hacker News Reader

Comment by cabacon | Hacker News Reader

He's totally right, but people have wanted this, and tried to implement it, several times. There's UPC (http://upc.lbl.gov/), Co-Array Fortran (http://www.co-array.org/), OpenMP (http://openmp.org/wp/), TBB (http://threadingbuildingblocks.org/), Cilk from MIT per scott_s, then there are the CUDA/OpenCL accelerator extensions ...

We don't need a call to arms without a pretty good idea of how to do it, and why it is different/better than the existing shots at parallelism. Jamming it into C/C++ is one idea, and making a new language like Fortress (http://en.wikipedia.org/wiki/Fortress_(programming_language) ) is another.

And those are all just the languages / language extensions. There's also the message-passing (MPI, PVM) vs. remote put-get (ARMCI/Global Arrays/...) It's clearly a hot topic with how multi-core chips are coming along. I didn't see much here that adds to the existing attempts, other than perhaps bemoaning that they are currently proprietary. That seems natural, though. With so many competing ideas, you see which one gains traction first, then work on incorporating it into the standards.

This call to arms is actually very concrete. It promotes Cilk Plus language extensions to C/C++. The author is trying to build momentum for baking Cilk Plus into GCC.

http://software.intel.com/en-us/articles/intel-cilk-plus-ope...

With so many competing ideas, you see which one gains traction first, then work on incorporating it into the standards.

But that's what he's promoting. Cilk has been around for a long time, since before the current multicore era.

I'd argue that compared to OpenMP and CUDA, Cilk has very little traction. My frame of reference is the current set of HPC platforms, though. We had one customer who wanted to build Cilk, and it was really just for R&D, not production.

I don't consider CUDA in the mix because it's designed specifically for GPUs. But, yes, OpenMP has much more traction in the HPC community, because it was designed by and for them. Its task parallelism, though, is rather ugly. I don't know what Cilk's data parallel abstractions look like, but I suspect they're better than OpenMP's task parallel abstractions. (Just because, well, I think OpenMP's are that bad.)

But, fundamentally, OpenMP is not integrated into the language. It's tacked onto the language through pragmas. I think that was a hack, not a long-term solution. And I say this as someone who did the exact same hack: http://people.cs.vt.edu/~scschnei/papers/scott_dissertation....

Agreed re: pragmas as a hack, but that's just the kind of thing you'd expect to get to gain traction, before folding into a language standard.

And re: data parallelism, I don't see that anyone has made a terribly popular implementations. The niche languages like UPC, CAF, and HPF all seem to have withered on the vine. So far, the only thing people seem to buy into is that openmp-based task parallelism is easier than managing threads by yourself.

Reply on news.ycombinator.com