在pthread上采用Cilk++

Question

我有这个问题已经有一段时间了。我在Cilk++上看了麻省理工学院的开放式课程。

使用线程的接口看起来很简单，这个工具看起来很有用。讲师解释了使用Cilk++代替pthread或OpenMP的优点。通过一般的书店浏览，我偶然发现了一本关于Cilk++的书。

但是，尽管麻省理工学院对现在由英特尔所有的Cilk++赞誉有加，但似乎几乎没有人采用它。

这一点的证据，无论它有多小或多么扭曲，都将是缺乏出版的书籍和追随者的数量或标签问题。(在撰写本文时)

亚马逊搜索给出

1. Cilk++ 2 results
2. pthreads 166 results
3. OpenMP 278 results

所以标签

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

Cilk++采用缓慢/少的可能原因是什么？

Answer 1

我想说，思想共享是人们不采用新技术的最大原因之一。就cilk++而言，它涵盖了许多替代技术“足以完成工作”的领域，例如boost.thread、POSIX线程、openMP和C++11中的新功能。

此外，任何新技术的采用曲线在开始时都非常缓慢。有些想法需要10年甚至更长的时间才能实现(悲哀但却是真的)。其他的则被归入现有的想法中。有些人因为糟糕而消失在历史中，有些人尽管很优秀，但却消失在历史中。

我认为英特尔决定保持Cilk++的开源，并在gcc中保持对它的支持将会有所帮助(假设他们使cilk++与C++11兼容)。我的感觉是，如果它成功了，它最终将被纳入C++，这并不是一件坏事。

更新2018年11月

cilk的支持是removed from gcc8。这可能是在支持openMP和TBB的intel deprecating it的背后。最近和正在进行的一些针对ISO C++并发性的添加使得cilk的语法糖不那么重要，而库解决方案更可取(以跟上步伐)。

基于任务的并行性包含在parallelism ts中，因此非常接近标准化(作为可选的额外功能)。

这方面的历史大致如下

• The cilk people在2012年的proposal N3409中建议将他们的增强功能添加到C++标准中。

，

• ，这被拒绝了，取而代之的是研究一种基于库的方法，很快就会导致http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3557.pdf，
• ，以及最近的http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4088.pdf，这似乎已经演变成我们今天所拥有的并行t的一部分。