4 c math pthreads scientific-computing openmp
我正在为科学计算社区开发代码,特别是迭代地求解线性方程组(Ax = b形式).
我已经使用BLAS和LAPACK进行原始矩阵子程序,但我现在意识到有一些手动并行化的余地.我正在开发一个共享内存系统,它有两个选择:OpenMP和PThreads.
假设时间不是最大的因素(代码的性能),这是一个更好的,未来的证明,也许是可移植的(到CUDA)并行化的方式？花在使用Pthreads上花费的时间是否值得提升？
我相信我的应用程序(基本上处理一次启动许多事情,然后根据所有这些"最佳"值运行)将受益于显式线程控制,但我担心编码会占用太多时间并且最终将没有绩效回报.
我已经在这里看过几个类似的问题,但它们都与一般应用有关.
这个涉及Linux中的通用多线程应用程序.
这也是一个普遍的问题.
我知道SciComp.SE,但觉得这里的主题更多.
您的问题看起来好像您希望OpenMP的编码效率高于Pthreads,Pthreads的执行效率高于OpenMP.总的来说,我认为你是对的.然而,不久前我决定我的时间比计算机的时间更重要,并选择了OpenMP.这不是我有理由后悔的决定,也不是我有任何确凿证据可以证实的决定.
但是你认为你的选择仅限于OpenMP和Pthreads是错误的,MPI(我假设你至少听说过这个,如果没有再发布的话)也将在共享内存机器上运行.对于某些应用程序,可以对MPI进行编程,使其在共享内存计算机上的性能不会太高.
三年前(+/-几年)科学开发人员工具箱中的基本并行化工具是OpenMP和MPI.使用这些工具的任何人都是大型用户社区的一部分,比Pthreads和MPI的用户社区更大(仅仅是轶事证据).今天,随着GPU和其他加速器逐渐涌现,情况更加分散,很难从HMPP,ACC,Chapel,MPI-3,OpenMP4,CUDA,OpenCL等中选出一名获胜者.我仍然认为OpenMP + MPI是一个有用的组合,但不能忽视块上的新孩子.
FWIW我致力于开发用于地球物理应用的计算EM代码,因此非常核心的"科学计算".