c++multithreadingpthreadscilkcilk-plus

Adoption of Cilk++ over pthreads

I have had this question for a while. I saw the MIT opencourseware lectures on Cilk++.
The interface for using threads looked straight forward and the tooling seemed useful. The lecturer explained the pros of using Cilk++ instead of pthread or OpenMP. Through general bookstore browsing I have come across a book on Cilk++ once.

But inspite of all the good things that MIT would say about Cilk++, which is now owned by Intel, it seems like there is little adoption of it.

Evidence of this, however small or skewed it could be, would be the lack of published books and the number or followers or tagged questions on SO. (at the time of writing)

Amazon search gives
1. Cilk++ 2 results
2. pthreads 166 results
3. OpenMP 278 results

SO tags
1. Cilk 11 followers
2. OpenMP 242 followers
3. pthreads 258 followers

What would be the possible reasons for the slow/little adoption of Cilk++?

Solution

  • I would say mind share is one of the biggest reasons people don't adopt a new technology. In the case of cilk++ it covers territory covered "well enough to get work done" by a number of alternative technologies such as boost.thread, posix threads, openMP and new features in C++11.

    Also the adoption curve of any new technology is very slow at the start. Some ideas take 10 years or longer to make it (sad but true). Others are subsumed into an existing idea. Some are lost to history because they were bad and some are lost to history in spite of being brilliant.

    I think Intel's decision to keep Cilk++ open source and maintain support for it in gcc will help (assuming they make cilk++ compliant with C++11). My feeling is that if it ever takes off it will end up being subsumed into C++ which would be no bad thing.

    Update Nov 2018

    cilk support was removed from gcc8. This is probably on the back of intel deprecating it in favour of openMP and TBB. There have been a number of recent and ongoing additions for concurrency for ISO C++ that make the syntactic sugar of cilk less important and a library solution more desirable (to keep pace).

    Task based parallelism is included in the parallelism ts and so is pretty close to standardisation (as an optional extra).

    The history of this is roughly as follows