切换到并行编码

时间:2020-03-06 14:20:06  来源:igfitidea点击:

我们都为单个处理器编写代码。
我想知道我们何时都能在多处理器上编写代码?

为此切换我们需要什么(软件工具,逻辑,算法)?

编辑:在我看来,由于我们并行执行许多任务,因此我们需要将那些现实生活中的解决方案(算法)转换为计算机语言。就像OOPs编码用于过程编码一样。 OOP是一种比程序更为实际的编码风格。所以我希望有这样的解决方案。

解决方案

没有简单的答案,而且在许多方面,即使是复杂的答案,目前也不足够或者不完整。如果我们对所需的答复更加具体,将会得到更好的答案:指向开发库和工具的指针,教学材料,当前研究项目的指针和该领域的问题,或者其他?

我认为最重要的要求是一门好的语言,它必须具有支持并行性的本机结构或者可以自动生成并行代码的结构。有相当多的语言适合该描述,但是没有一种语言足够流行,因此不能真正考虑用于主流。这又是由以下几种原因引起的:

  • 从本质上讲,这些语言与当今的命令式语言有很大不同,因此很难学习(或者至少看起来是这样)。
  • 他们通常缺乏良好的工具和库,这使它们无法用于任何"实际"项目。

当然,如果它更流行,那么更多的人会愿意学习它,并且会有更多的支持,因此这是一个很难打破的循环。我想我们所能做的就是希望。 :)

考虑到大量并行化设计的语言的一个示例是Erlang,它实际上已用于商业项目中。

不幸的是,对于大规模并发编程,除非在编译器方面有所帮助,否则我们将抛弃对算法的了解(我认为Don Knuth甚至这么说)。阅读有关Erlang的信息,以了解这个可能的未来。

我们需要的是高度并行算法的自然抽象。 Actor(认为:Erlang)在这个方向上走了很长一段路,但是它们并不是万能的解决方案。一些更具体的抽象,例如fork / join或者map / reduce甚至可以更容易地应用于常见问题。

所有这些并发抽象的诀窍是它们需要函数式编程。并发不能与共享的可变状态很好地配合。正如他们所说,"锁被认为是有害的"。由于大多数开发人员都来自严格的命令性背景,因此切换到无共享的连续传递方法通常极具挑战性。

顺便说一下,关于并发抽象,Clojure在这个方向上具有一些非常有趣的功能。它不仅具有排序参与者,而且还定义了事务性内存模型(例如数据库)以及全局的原子引用机制。这两个功能允许并发操作共享"可变"状态,而不必担心锁定或者竞争条件。

最后,它取决于教育。并发抽象所需的许多理论工作已经完成,我们只需要接受就可以了。不幸的是,正如Erlang和Haskell所证明的那样,有时最好的想法仍然落在极端边缘的人群中。希望像Scala和Clojure这样的努力将成功地将更高级的抽象带入主流,并将它们潜入到一个现有的,受支持的平台(JVM)上。

最重要的要求是能够将问题分解为可以彼此独立解决的较小问题。一旦确定了如何执行此操作,其他所有内容都将更易于考虑,并会遇到进一步的实施问题(例如"计算的一部分取决于其他部分,我如何等待它们完成?")具体化,我们可以在此处研究或者询问的具体事物。

有几种流行或者正在流行的工具/语言。如果使用FORTRAN,C或者C ++,则可以使用OpenMP(不太难实现)或者消息传递接口(MPI)库(强大而又有最大的提速潜力,但也很复杂和困难)。 OpenMP使用预处理器指令来标记可以并行化的区域,尤其是循环。 MPI使用在流程之间来回传递数据的消息,最大的困难是保持所有内容同步,而不会遇到瓶颈并使流程等待。我要说的是,MPI肯定正在淘汰。在科学/高性能计算社区中,很明显,提速很少值得花费额外的开发时间。

至于即将到来的语言,请查看堡垒。它仍在设计中,但目标是创建一种比FORTRAN更易于科学计算的语言。程序将以非常高级的数学语法指定。另外,并行性将是隐式的。程序员将不得不工作以串行方式进行操作。另外,它受到Sun的拥护并且基于Java,因此它将是可移植的。