是否还值得为OpenMP实施投入时间？

Question

由于clang / llvm无法在短期内支持OpenMP，因此英特尔在TBB库的道路上走得很远。是否仍然值得在OpenMP之上实现多线程科学库（我正在研究ccv：http://github.com/liuliu/ccv）？尽管有各种各样的批评，我对OpenMP的体验非常高兴（它非常易于使用，性能提升也很合理）。但如果它是一种濒临死亡的技术，那么C中更容易多线程的替代是什么？ （不是pthread，而TBB是C ++的东西）。谢谢！

Answer 1

OpenMP运行良好，甚至将其扩展到多核类型的东西也做了一些努力。遗憾地加入OpenMP在Clang的优先级列表中并不高，但所有现有的编译器供应商（英特尔，gcc，pgi等）不仅致力于现有的实现，还致力于标准的持续发展。我不担心;最终clang / llvm会到来。

Answer 2

如果查看C++11 feature support in clang list，您会注意到并发支持完全不存在。

因此，即使新的C ++标准实际上提供了并发和多线程的强大功能，但如果我们想要保持平台独立，我们目前还无法真正使用它。

因此，如果您有现有的OpenMP代码，请不要冒汗; clang根本不受支持，虽然很可惜，但仅仅因为它而改用另一种技术是没有意义的。当然你可以使用TBB，但我会说根据C ++ 11并发TBB无论如何都只是一种过渡技术。

就个人而言，我很高兴看到最后一个OpenMP，但目前我们还没有。

Answer 3

新的C标准C11对线程有自己的支持，它遵循一个细分的pthreads模型。 （C ++ 11具有相同的，BTW）但是，这不能取代OpenMP，它简单地处理并行循环和减少等等。

有一个值得研究的“新”工具_Atomic。经典的线程库只为你提供互斥体以避免竞争，在某些数据拥塞时，这种情况可能非常繁重。无论如何，_Atomic最终为处理器在大多数情况下提供的功能提供了一个低级语言接口，并且它允许您在没有比赛的线程之间快速更新计数器或类似的东西。

_Atomic和OpenMP应该合作没有问题。