科学计算中基于任务的共享内存并行库

近年来，出现了一些库/软件项目，它们提供了某种形式的通用数据驱动的共享内存并行性。

主要思想是，程序员无需编写显式的线程代码，而是将其算法实现为相互依赖的任务，然后由共享内存计算机上的通用中间件动态调度这些任务。

此类库的示例是：

• 夸克：最初是为MAGMA并行线性代数库设计的，似乎也已用于并行快速多极子方法。

• Cilk：最初是一个基于MIT的项目，现在得到了Intel的支持，实现为C的语言/编译器扩展，用于Cilkchess计算机国际象棋软件以及FFTW中。

• SMP superscalar：在巴塞罗那超级计算中心开发，基于#pragma扩展在很多方面类似于Cilk 。

• StarPU：基于类似库的“小代码”，可以针对几种不同的体系结构（包括GPU）进行编译和调度。

• OpenMP任务：从3.0版开始，OpenMP引入了可以异步调度的“任务”（请参阅​​规范的2.7节）。

• 英特尔的线程构建基块：使用C ++类创建和启动异步任务，请参阅教程的第11节。

• OpenCL：在多核上支持基于任务的并行性。

尽管有很多文献描述了这些库/语言扩展的内部工作方式以及它们在特定问题上的应用，但我仅遇到了很少的例子将它们用于科学计算应用中。

所以这是一个问题：是否有人知道使用这些库/语言扩展中的任何一个或类似的用于共享内存并行性的科学计算代码？

deal.II在整个库中使用了线程构建模块，总的来说，我们对此感到满意。我们已经研究了一些替代方案，特别是OpenMP，因为每个人似乎都将其用于更简单的代码，但发现它们缺乏。特别是，OpenMP具有一个巨大的缺点，即其任务模型不允许您获取启动任务的句柄，因此很难访问任务的状态（例如，等待任务完成）或返回值。您在单独的任务上运行的功能。OpenMP主要用于并行化最内部的循环，但是您可以通过并行化最外部的复杂循环来获得并行效率，而OpenMP并不是用于并行化的工具，而TBB则可以。

在我看来，这些系统相对不成功，主要是由于以下原因。

• 幼稚的观点是，并行计算比使存储器局部化和删除同步点更能使计算（例如触发器）并行化。即使诸如稠密矩阵算法之类的某些问题仍然受FP限制，但这仅在仔细考虑了内存子系统之后才会发生，并且大多数计算内核（尤其是在PDE世界中）对内存更加敏感。工作队列倾向于权衡内存局部性，以实现更好的初始天平平衡和更多的原子内存操作（由于通过队列进行同步）。
• 依靠过度分解来实现动态负载平衡，但要以强大的可伸缩性为代价。任务通常具有重叠的数据依赖性（重影值）。随着内部空间的缩小，重影/内部比率增加。即使这并不意味着多余的工作，也意味着内存移动增加。可以通过诸如协作预取之类的方法来显着减少内存带宽需求，在协作预取中，多个线程通过对其邻居的软件预取来共享L1或L2高速缓存（这将使线程组保持大致一致）。这与过度分解完全相反。
• 不可预测的性能，主要是由于上述与内存相关的问题。
• 缺少库友好的组件。几乎可以总结为没有类似物，MPI_Comm后者允许不同的库执行丰富的操作而不会发生冲突，并且无法在库之间传递上下文并恢复必要的属性。无论使用共享还是分布式内存，“通信器”提供的抽象对于库组成都很重要。