4 ms·
He's totally right, but people have wanted this, and tried to implement it, several times. There's UPC (http://upc.lbl.gov/ http://upc.lbl.gov/), Co-Array Fort
by cabacon 15y ago
He's totally right, but people have wanted this, and tried to implement it, several times. There's UPC (http://upc.lbl.gov/ http://upc.lbl.gov/), Co-Array Fortran (http://www.co-array.org/ http://www.co-array.org/), OpenMP (http://openmp.org/wp/ http://openmp.org/wp/), TBB (http://threadingbuildingblocks.org/ 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) 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.
- scott_s 15y agoWith 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.
- cabacon 15y agoI'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.
- scott_s 15y agoI 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.pdf http://people.cs.vt.edu/~scschnei/papers/scott_dissertation....
- cabacon 15y agoAgreed 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.
- aklein 15y agoThis 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-open-source/ http://software.intel.com/en-us/articles/intel-cilk-plus-ope...