我正在为科学计算社区开发代码，特别是用于迭代求解线性方程组(Ax=b 形式)。
我已经将 BLAS 和 LAPACK 用于原始矩阵子例程，但我现在意识到手动并行化有一定的范围。我正在开发一个共享内存系统，这让我有 2 个选择:OpenMP 和 PThreads。
假设时间不是最重要的因素(代码的性能才是)，这是一种更好的、面向 future 的并且可能是可移植的(到 CUDA)并行化方式？花在使用 Pthreads 上的时间是否值得性能提升？
我相信我的应用程序(它基本上处理一次启动许多事情，然后根据所有这些事情的“最佳”值进行操作)将受益于显式线程控制，但我担心编码会占用太多时间最终不会有任何绩效返回。
我已经在这里查看了一些类似的问题，但它们都与一般应用有关。
This 一个是关于 Linux 中的通用多线程应用程序。
This 也是一个普遍的问题。
我知道 SciComp.SE，但觉得它更多地是关于这里的主题。
最佳答案
您的问题读起来好像您期望 OpenMP 的编码效率将高于 Pthreads，并且 Pthreads 的执行效率高于 OpenMP。总的来说，我认为你是对的。然而，不久前我决定我的时间比我的电脑时间更重要，并选择了 OpenMP。这不是我有理由后悔的决定，也不是我有任何确凿证据可以证实的决定。
但是，您错误地认为您的选择仅限于 OpenMP 和 Pthreads，MPI(我假设您至少听说过这个，如果没有，请再次发布)也将在共享内存机器上运行。对于某些应用程序，MPI 可以通过编程在共享内存的计算机上轻松胜过 OpenMP。
三年前(+/- 几年)，科学开发人员工具箱中的基本并行化工具是 OpenMP 和 MPI。任何使用这些工具的人都是一个庞大的用户社区的一部分，比 Pthreads 和 MPI 的用户社区更大(仅传闻证据)。今天，随着 GPU 和其他加速器的出现，情况更加分散，很难从 HMPP、ACC、Chapel、MPI-3、OpenMP4、CUDA、OpenCL 等中选出一个赢家。我仍然认为OpenMP+MPI 是一个有用的组合，但不能忽略块上的新 child 。
FWIW 我致力于开发用于地球物理应用的计算 EM 代码，因此非常核心的“科学计算”。
关于c - 科学计算::OpenMP 或 Pthreads，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/9850437/