您使用哪些并行编程 API? [英] Which parallel programming APIs do you use?

问题描述

考虑到当今多核和多处理硬件的巨大重要性，试图了解人们目前实际上是如何编写并行代码的.对我来说，占主导地位的范式似乎是 pthreads(POSIX 线程)，它在 Linux 上是原生的，在 Windows 上可用.HPC 人员倾向于使用 OpenMP 或 MPI，但在 StackOverflow 上这些似乎并不多.或者您是否依赖 Java 线程、Windows 线程 API 等而不是可移植标准?在您看来，进行并行编程的推荐方法是什么?

Trying to get a grip on how people are actually writing parallel code currently, considering the immense importance of multicore and multiprocessing hardware these days. To me, it looks like the dominant paradigm is pthreads (POSIX threads), which is native on Linux and available on Windows. HPC people tend to use OpenMP or MPI, but there are not many of these here on StackOverflow it seems. Or do you rely on Java threading, Windows threading APIs, etc. rather than the portable standards? What is the recommended way, in your opinion, to do parallel programming?

或者你在使用更奇特的东西，比如 Erlang、CUDA、RapidMind、CodePlay、Oz，甚至是亲爱的老 Occam?

Or are you using more exotic things like Erlang, CUDA, RapidMind, CodePlay, Oz, or even dear old Occam?

澄清:我正在寻找非常便携且适用于各种主机架构上的 Linux、各种 unix 等平台的解决方案.Windows 是一种很好支持的罕见案例.所以 C# 和 .net 在这里真的太狭隘了，CLR 是一项很酷的技术，但他们能否请他们为 Linux 主机发布它，以便它像 JVM、Python、Erlang 或任何其他可移植语言一样流行.

Clarification: I am looking for solutions that are quite portable and applicable to platforms such as Linux, various unixes, on various host architectures. Windows is a rare case that is nice to support. So C# and .net are really too narrow here, the CLR is a cool piece of technology but could they PLEASE release it for Linux host so that it would be as prevalent as say the JVM, Python, Erlang, or any other portable language.

C++ 或基于 JVM:可能是 C++，因为 JVM 倾向于隐藏性能.

C++ or JVM-based: probably C++, since JVMs tend to hide performance.

MPI:我同意，即使是 HPC 人员也认为它是一个难以使用的工具——但对于在 128000 个处理器上运行，它是解决 map/reduce 不适用的问题的唯一可扩展解决方案.不过，消息传递非常优雅，因为它是唯一一种似乎可以很好地扩展到本地内存/AMP、共享内存/SMP、分布式运行时环境的编程风格.

MPI: I would agree that even the HPC people see it as a hard to use tool -- but for running on 128000 processors, it is the only scalable solution for the problems where map/reduce do not apply. Message-passing has great elegance, though, as it is the only programming style that seems to scale really well to local memory/AMP, shared memory/SMP, distributed run-time environments.

一个有趣的新竞争者是 MCAPI.但我认为还没有人有时间对此有任何实际经验.

An interesting new contender is the MCAPI. but I do not think anyone has had time to have any practical experience with that yet.

所以总的来说，情况似乎是有很多我不知道的有趣的 Microsoft 项目，而 Windows API 或 pthreads 是实践中最常见的实现.

So overall, the situation seems to be that there are a lot of interesting Microsoft projects that I did not know about, and that Windows API or pthreads are the most common implementations in practice.

推荐答案

MPI 并不像大多数人想象的那么难.现在我认为多范式方法最适合并行和分布式应用程序.使用 MPI 进行节点到节点的通信和同步，并使用 OpenMP 或 PThreads 进行更细粒度的并行化.想想每台机器的 MPI，以及每个内核的 OpenMP 或 PThreads.这似乎比在不久的将来为每个核心产生一个新的 MPI Proc 更好一点.

MPI isn't as hard as most make it seem. Nowadays I think a multi-paradigm approach is best suited for parallel and distributed applications. Use MPI for your node to node communication and synchronization and either OpenMP or PThreads for your more granular parallelization. Think MPI for each machine, and OpenMP or PThreads for each core. This would seem to scale a little bit better than spawning a new MPI Proc for each core for the near future.

也许现在对于双核或四核来说，为机器上的每个内核生成一个 proc 不会有那么多开销，但是随着我们接近每台机器越来越多的内核，其中缓存和芯片上的内存没有扩展同样，使用共享内存模型会更合适.

Perhaps for dual or quad core right now, spawning a proc for each core on a machine won't have that much overhead, but as we approach more and more cores per machine where the cache and on die memory aren't scaling as much, it would be more appropriate to use a shared memory model.

这篇关于您使用哪些并行编程 API?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！