c++ - 在 pthreads 上采用 Cilk++

Question

这个问题我已经有一段时间了。看了MIT的Cilk++开放课件讲座。
使用线程的界面看起来很直接，而且工具似乎很有用。讲师解释了使用 Cilk++ 而不是 pthread 或 OpenMP 的优点。通过一般的书店浏览，我偶然发现了一本关于 Cilk++ 的书。

但是，尽管麻省理工学院对 Cilk++(现在归英特尔所有)说了很多好话，但似乎很少有人采用它。

这方面的证据，无论多么小或有偏差，都将是缺乏已出版的书籍以及关于 SO 的数量或关注者或标记的问题。 (在撰写本文时)

亚马逊搜索给
1. Cilk++ 2个结果
2. pthreads 166 个结果
3. OpenMP 278 结果

SO标签
1. Cilk 11 关注者
2. OpenMP 242 关注者
3. pthreads 258 关注者

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

Answer 1

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

此外，任何新技术的采用曲线在开始时都非常缓慢。有些想法需要 10 年或更长时间才能实现(悲伤但真实)。其他人被纳入现有的想法。有的人因为烂而被历史遗忘，有的人虽然辉煌却被历史遗忘。

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

2018 年 11 月更新

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

基于任务的并行性包含在 parallelism ts 中因此非常接近标准化(作为可选的附加项)。

这段历史大致如下

• cilk 人在 2012 年的提案 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这似乎已经演变成我们今天拥有的并行性的一部分。