切换到并行编码
我们都为单个处理器编写代码。 我想知道我们什么时候能够在多处理器上编写代码？切换到并行编码
这个开关我们需要什么（软件工具，逻辑，算法）？
编辑：在我看来，因为我们平行地完成许多任务，所以我们需要将这些现实生活中的解决方案（算法）转换为计算机语言。就像OOP编码为程序编码做的一样。面向对象编程风格比程序风格更加真实。所以我希望有这样的解决方案。
没有简单的答案，并且在许多方面，即使是复杂的答案目前还不够完善或不完整。如果你对你想要的回复有更具体的了解，那么你会得到更好的答案：指向开发库和工具，教学材料，当前研究项目的指针和这方面的问题或其他内容？
我认为最重要的要求是具有支持并行性的原生构造或可以自动生成并行代码的良好语言。有相当多的语言符合这种描述，但没有一种足够流行，足以真正被认为是主流使用。在，又被几件事情引起的：
- 就其本质而言，这些语言从今天的命令式语言非常不同，并为此更难学习（或至少似乎是这样）。
- 他们经常缺乏好的工具和库，使他们无法用于任何“真实”的项目。
当然，如果它更受欢迎，更多的人会愿意学习它，并会有更多的支持，所以这是一种很难摆脱的周期。我想我们所能做的就是希望。 :)
Erlang设计的语言设计的例子 - 它实际上用于商业项目。
不幸的是，对于大规模并发编程 - 除非编译器有帮助突破，否则我们会抛出许多关于算法的知识（我认为Don Knuth甚至会这么说）。阅读关于Erlang的一瞥可能的未来。
我们需要的是高并发算法的自然抽象。参与者（想想：Erlang）在这个方向上走了很长的路，但他们不是一个万能的解决方案。一些更具体的抽象如fork/join或map/reduce可以更容易地应用于常见问题。
所有这些并发抽象的诀窍是它们需要功能风格的编程。并发性与共享的可变状态无法很好地匹配。正如他们所说的，“锁被认为是有害的”。由于大多数开发人员来自严格必要的背景，切换到无共享延续传递方法通常极具挑战性。顺便提一句，关于并发抽象，Clojure在这个方向上有一些非常有趣的特性。它不仅具有排序的参与者，还定义了一个事务性内存模型（思考：数据库）以及全局的原子参考机制。这两个特性允许并发操作共享“可变”状态，而不必担心锁定或竞态条件。
最后，它归结为教育。对并发抽象所需的大部分理论工作已经完成，我们只需要接受它。不幸的是，正如Erlang和Haskell所证明的那样，有时候最好的想法仍然是一个非常边缘的人群。希望像Scala和Clojure这样的努力能够成功地将更先进的抽象技术带入主流，将它们潜入现有的支持良好的平台（JVM）。
最重要的要求是能够将问题分解为可以彼此独立解决的较小问题。一旦你研究了你将如何做到这一点，那么其他一切都会更容易思考和实施的进一步问题（例如“我的计算部分取决于其他部分 - 我该如何等待他们完成？”）。 ）成为具体的，具体的事情，你可以研究或问这里。
有几种工具/语言流行或正在流行。如果您使用FORTRAN，C或C++，则可以使用OpenMP（不太难实现）或Message Passing Interface（MPI）库（强大且最大的加速潜力，但也是复杂且困难的）。 OpenMP使用预处理器指令来标记可以并行化的区域，特别是循环。 MPI使用在进程之间来回传递数据的消息，最大的困难在于保持所有内容的同步，而不会造成瓶颈和等待进程。然而，我想说MPI绝对是在出路。在科学/高性能计算社区中已经很清楚，加速很少值得额外的开发时间。
至于未来的语言，请查看Fortress。它仍在设计中，但其目标是创建比FORTRAN更易于科学计算的语言。程序将以非常高的数学语法指定。另外，并行将是隐含的;程序员必须努力工作才能连续完成任务。另外，它受到Sun的支持，并基于Java，所以它将是可移植的。
对于java，你现在可以看看并行Java库或DPJ（确定性并行Java！） 它将为您提供从代码提取并行性很大的帮助！
在我看来，因为我们平行地完成许多任务，我们需要将这些真实生活解决方案（算法）转换为计算机语言的相同方式。就像OOPs编码为程序编码做的一样。面向对象编程风格比程序风格更加真实。 所以我希望有这样的解决方案。 – 2008-09-18 05:47:03