您今天建议使用哪种并行编程模型来利用未来的众核处理器？

Question

如果您今天从头开始编写一个新的应用程序,并希望它可以扩展到明天可以使用的所有内核,您会选择哪种并行编程模型/系统/语言/库？为什么？

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

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

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

Answer 1

多核编程实际上可能需要不止一种范例.目前的一些竞争者是:

1. MapReduce.这很适用于可以将问题轻松分解为并行块的情况.
2. 嵌套数据并行.这类似于MapReduce,但实际上支持问题的递归分解,即使递归块的大小不规则.寻找NDP在大规模并行但有限的硬件(如GPU)上运行的纯函数式语言中取得巨大成功.
3. 软件事务内存.如果你需要传统的线程,STM让它们变得可以忍受.您在关键部分获得了50%的性能影响,但您可以将复杂的锁定方案扩展到100个处理器而不会感到痛苦.但是,这不适用于分布式系统.
4. 并行线程对象与消息.Erlang使用这个非常聪明的模型.每个"对象"都变成一个轻量级线程,对象通过异步消息和模式匹配进行通信.它基本上是真正的并行OO.这在几个实际应用程序中取得了很好的成功,并且对于不可靠的分布式系统非常有用.

其中一些范例可以为您提供最大的性能,但只有在问题彻底分解时才能发挥作用.其他人牺牲了一些性能,但允许更多种算法.我怀疑上述的某些组合最终将成为标准工具包.

Answer 2

我真正喜欢的两个解决方案是加入微积分(JoCaml,Polyphonic C#,Cω)和演员模型(Erlang,Scala,E,Io).

软件事务内存给我留下了特别深刻的印象.它只是感觉它只是允许线程坚持生命一段时间,即使它们应该在几十年前就已经消亡.但是,它确实有三个主要优点:

1. 人们了解数据库中的交易
2. 已有关于事务RAM硬件的讨论
3. 尽管我们都希望它们消失,但线程可能会成为未来几十年的主要并发模型,这可能是令人遗憾的.STM可以显着减轻疼痛.

Answer 3

mapreduce/hadoop范例很有用,也很有用.特别是对于那些习惯于像perl这样的语言的人来说,映射数组并对每个元素进行一些操作的想法应该非常流畅和自然,而mapreduce/hadoop只是将它带到下一个阶段,并说没有理由数组的每个元素都需要在同一台机器上处理.

从某种意义上说,它更受战斗考验,因为谷歌正在使用mapreduce,并且很多人一直在使用hadoop,并且已经证明它适用于通过网络在多台机器上扩展应用程序.如果您可以跨网络扩展多台计算机,则可以在一台计算机上扩展多个核心.

Answer 4

对于.NET应用程序,我选择" .NET Parallel Extensions(PLINQ) ",它非常易于使用,并允许我在几分钟内并行化现有代码.

1. 这很容易学习
2. 用于对大型对象数组执行复杂操作,因此我无法对其他应用程序发表评论
3. 支持任务和piplines
4. 应该支持未来几年,但谁知道肯定？
5. CTP版本有一些性能问题,但看起来非常有前途.

Mono 可能会获得对PLINQ的支持,因此它也可能是一个跨平台的解决方案.

Answer 5

对于繁重的计算等,像Haskell这样的纯函数式语言很容易并行化,而不需要程序员的任何努力.除了学习Haskell之外,就是这样.

但是,我不认为这是(近)未来的方式,仅仅是因为太多的程序员已经习惯了命令式编程范式.

Answer 6

kamaelia是一个python框架,用于构建具有大量通信进程的应用程序.

Kamaelia - 并发变得有用,有趣

在Kamaelia中,您可以使用简单的组件构建系统,这些组件可以相互通信.这加速了开发,大规模地帮助维护,也意味着您可以构建自然并发的软件.它旨在供任何开发人员访问,包括新手.它也很有趣:)

什么样的系统？网络服务器,客户端,桌面应用程序,基于游戏的游戏,转码系统和管道,数字电视系统,垃圾邮件根除者,教学工具以及更多的数量:)

另请参阅问题多核和并发 - 语言,库和开发技术