OpenMP标准仅考虑C++ 98(ISO/IEC 14882:1998).这意味着在C++ 03甚至C++ 11下没有标准的OpenMP支持用法.因此,任何使用C++> 98和OpenMP的程序都在标准之外运行,这意味着即使它在某些条件下工作,它也不太可能是可移植的,但绝对不能保证.
C++ 11具有自己的多线程支持,情况更糟,这很可能会在某些实现中与OpenMP发生冲突.
那么,将OpenMP与C++ 03和C++ 11一起使用有多安全？
可以安全地在一个相同的程序中使用C++ 11多线程和OpenMP但不交错它们(即在任何代码中没有传递给C++ 11并发特性的OpenMP语句,并且线程中没有C++ 11并发由OpenMP产生)？
我特别感兴趣的是我首先使用OpenMP调用一些代码,然后在相同的数据结构上使用C++ 11并发代码调用其他代码.
Hri*_*iev 25
沃尔特,我相信我不仅告诉你当前事物的状态,其他的讨论,也从源头上为您提供了直接的信息(即从我的同事谁是OpenMP的语言委员会的一部分).
OpenMP被设计为FORTRAN和C的轻量级数据并行添加,后来扩展到C++惯用语(例如,随机访问迭代器上的并行循环),并通过引入显式任务来实现任务并行性.它旨在尽可能多地在尽可能多的平台上移植,并在所有三种语言中提供基本相同的功能.它的执行模型非常简单 - 单线程应用程序在并行区域中分配线程团队,在内部运行一些计算任务,然后将团队重新连接到串行执行.如果启用了嵌套并行性,并行团队中的每个线程都可以在以后分叉自己的团队.
由于OpenMP的主要用途是高性能计算(毕竟,其指令和执行模型来自High Performance Fortran),因此任何OpenMP实现的主要目标都是效率,而不是与其他线程范例的互操作性.在某些平台上,只有在OpenMP运行时是控制进程线程的唯一运行时,才能实现高效实现.此外,OpenMP的某些方面可能无法与其他线程结构一起使用,例如,OMP_THREAD_LIMIT在分支两个或多个并发并行区域时设置的线程数限制.
由于OpenMP标准本身并不严格禁止使用其他线程范例,但是既没有标准化与此类的互操作性,支持这样的功能取决于实现者.这意味着某些实现可能会提供顶级OpenMP区域的安全并发执行,有些可能不会.x86实现者承诺支持它,可能是因为他们中的大多数也是其他执行模型的支持者(例如,带有Cilk和TBB的英特尔,带有C++ 11的GCC等),x86通常被认为是"实验性"平台(其他供应商通常要保守得多).
对于它采用的C++特性,OpenMP 4.0也没有比ISO/IEC 14882:1998更进一步(SC12草案就在这里).该标准现在包括诸如可移植线程亲和力之类的东西 - 这绝对不能与其他线程范例很好地结合,这可能提供它们自己的绑定机制,与OpenMP的绑定机制相冲突.OpenMP语言再次针对HPC(数据和任务并行科学和工程应用程序).C++ 11构造针对通用计算应用程序.如果你想看中C++ 11并发的东西,然后用C++ 11只,或者如果你真的需要它使用OpenMP混合,然后坚持的语言功能的C++ 98集,如果你想留便携.
我特别感兴趣的是我首先使用OpenMP调用一些代码,然后在相同的数据结构上使用C++ 11并发代码调用其他代码.
没有明显的理由让你想要的不可能,但这取决于你的OpenMP编译器和运行时.有一些免费和商业库使用OpenMP进行并行执行(例如MKL),但是总是有警告(尽管有时隐藏在用户手册中)可能与多线程代码不兼容,这些代码提供了可能的内容和时间的信息.与往常一样,这超出了OpenMP标准的范围,因此也是YMMV.
小智 5
像Jim Cownie一样,我也是英特尔员工.我同意他的观点,英特尔线程构建模块(英特尔TBB)可能是一个不错的选择,因为它具有像OpenMP这样的循环级并行,但也有其他并行算法,并发容器和低级功能.TBB试图跟上当前的C++标准.
为了澄清Walter,英特尔TBB包括parallel_reduce算法以及对原子和互斥体的高级支持.
您可以在http://software.intel.com/sites/products/documentation/doclib/tbb_sa/help/tbb_userguide/title.htm找到英特尔®线程构建模块的用户指南 .用户指南概述了该功能.图书馆.
| 归档时间： |
|
| 查看次数： |
8776 次 |
| 最近记录： |