您今天推荐哪种并行编程模型来利用明天的多核处理器? [英] What parallel programming model do you recommend today to take advantage of the manycore processors of tomorrow?

问题描述

如果您今天要从头开始编写新的应用程序，并希望将其扩展到明天可以使用的所有内核，那么您将选择哪种并行编程模型/系统/语言/库?为什么?

If you were writing a new application from scratch today, and wanted it to scale to all the cores you could throw at it tomorrow, what parallel programming model/system/language/library would you choose? Why?

我对这些方面的答案特别感兴趣:

I am particularly interested in answers along these axes:

1. 程序员的生产率/易用性(凡人都能成功使用吗?)
2. 目标应用程序域((不)擅长什么问题?)
3. 并发样式(它是否支持任务，管道，数据并行性，消息...?)
4. 可维护性/面向未来(在20年内还会有人使用它吗?)
5. 性能(如何扩展到哪种硬件上?)

1. Programmer productivity / ease of use (can mortals successfully use it?)
2. Target application domain (what problems is it (not) good at?)
3. Concurrency style (does it support tasks, pipelines, data parallelism, messages...?)
4. Maintainability / future-proofing (will anybody still be using it in 20 years?)
5. Performance (how does it scale on what kinds of hardware?)

我故意模糊应用程序的性质，以期获得对各种应用程序有用的良好通用答案.

I am being deliberately vague on the nature of the application in anticipation of getting good general answers useful for a variety of applications.

推荐答案

多核编程实际上可能需要多个范例.当前的一些竞争者是:

Multi-core programming may actually require more than one paradigm. Some current contenders are:

1. MapReduce .在将问题轻松分解为并行块的情况下，此方法效果很好.
2. 嵌套数据并行化.这类似于MapReduce，但实际上支持问题的递归分解，即使递归块的大小不规则也是如此.希望NDP在运行于大规模并行但有限的硬件(例如GPU)上运行的纯功能语言中大获成功.
3. 软件事务存储.如果您需要传统线程，则STM使它们可以承受.您在关键部分会损失50％的性能，但是您可以轻松地将复杂的锁定方案扩展到100个处理器.但是，这不适用于分布式系统.
4. 带有消息传递的并行对象线程.这个非常聪明的模型被Erlang使用.每个对象"成为一个轻量级线程，并且对象通过异步消息和模式匹配进行通信.基本上是真正的并行OO.在一些实际应用中，它已经取得了很好的成功，并且对于不可靠的分布式系统也非常有用.

1. MapReduce. This works well where a problem can be easily decomposed into parallel chunks.
2. Nested Data Parallelism. This is similar to MapReduce, but actually supports recursive decomposition of a problem, even when the recursive chunks are of irregular size. Look for NDP to be a big win in purely functional languages running on massively parallel but limited hardware (like GPUs).
3. Software Transactional Memory. If you need traditional threads, STM makes them bearable. You pay a 50% performance hit in critical sections, but you can scale complex locking schemes to 100s of processors without pain. This will not, however, work for distributed systems.
4. Parallel object threads with messaging. This really clever model is used by Erlang. Each "object" becomes a lightweight thread, and objects communicate by asynchronous messages and pattern matching. It's basically true parallel OO. This has succeeded nicely in several real-world applications, and it works great for unreliable distributed systems.

其中一些范例可为您提供最佳性能，但只有在问题能够清晰分解的情况下才能发挥作用.其他人则牺牲了一些性能，但允许使用更多种算法.我怀疑以上各项的某种组合最终将成为标准工具箱.

Some of these paradigms give you maximum performance, but only work if the problem decomposes cleanly. Others sacrifice some performance, but allow a wider variety of algorithms. I suspect that some combination of the above will ultimately become a standard toolkit.

这篇关于您今天推荐哪种并行编程模型来利用明天的多核处理器?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！