多核系统的编程与编译状态

Question

我正在对多核处理器进行一些研究；具体来说，我正在研究为多核处理器编写代码，以及为多核处理器编译代码。

我对这一领域的主要问题感到好奇，这些问题目前将阻止广泛采用编程技术和实践来充分利用多核体系结构的功能。

我知道以下工作(其中一些似乎与多核体系结构没有直接关系，但似乎与并行编程模型、多线程和并发有更多的关系)：

• 二郎 (我知道Erlang包含结构以促进并发性，但我不确定如何将其用于多核体系结构)
• OpenMP (似乎主要与多处理和利用集群的能力有关)
• 统一并行C
• 克尔克
• Intel线程块 (这似乎与多核系统直接相关，因为它来自英特尔，这是有意义的。)除了定义某些编程构造之外，它似乎还具有一些功能，可以告诉编译器优化多核体系结构的代码)。

一般来说，从我对多线程编程的很少经验来看，我知道考虑并发性和并行性的编程绝对是一个困难的概念。我还意识到多线程编程和多核编程是两件不同的事情。在多线程编程中，您确保CPU不会保持空闲状态(在单CPU系统上)。正如James所指出的，操作系统可以安排不同的线程在不同的核心上运行--但我更感兴趣的是从语言本身或通过编译器来描述并行操作。据我所知，您不能真正地执行并行操作。在多核系统中，您应该能够执行真正的并行操作。

因此，在我看来，目前多核编程面临的问题是：

• 多核编程是一个困难的概念，需要很高的技巧。
• 在当今的编程语言中，没有一个为多核环境的程序提供良好抽象的本地构造。
• 除了Intel的TBB库之外，我还没有在其他编程语言中找到利用多核体系结构进行编译的能力的努力(例如，我不知道Java或C#编译器是优化了多核系统的字节码，还是JIT编译器做到了这一点)

我感兴趣的是知道还有哪些其他问题，以及是否有任何解决方案来解决这些问题。链接到研究论文(以及这种性质的东西)会有帮助。谢谢!

编辑

如果我不得不把我的问题浓缩成一句话，那就是:今天多核编程面临的问题是什么?在这个领域正在进行什么研究来解决这些问题？

更新

在我看来，有三个层次需要关注多核：

1. 语言级：抽象并行化和并发性的构造/概念/框架，使程序员更容易表达相同的内容
2. 编译器级别的：如果编译器知道它正在编译的是什么体系结构，它可以优化该体系结构的编译代码。
3. OS级别的：操作系统优化正在运行的进程，并可能安排不同的线程/进程在不同的核心上运行。

我在ACM和IEEE上搜索过，发现了一些论文。他们中的大多数都谈到并发思考有多困难，以及当前的语言是如何没有正确的方法来表示并发性的。有些人甚至声称，我们现有的并发模型(线程)并不是处理并发的好方法(即使在多个核上)。我想听听别人的看法。

Answer 1

多核编程的主要问题与编写其他并发应用程序一样，但在计算机中使用多个cpu以前并不常见，但现在很难找到任何只有一个核心的现代计算机，因此，要利用多核、多cpu体系结构，就会面临新的挑战。

但是，这个问题是一个老问题，每当计算机体系结构超越编译器时，它似乎就会倒退到函数式编程，因为如果严格遵循这种编程模式，可以使程序非常可并行，例如，您没有任何全局可变变量。

但是，并不是所有的问题都可以很容易地使用FP，因此我们的目标是如何使其他编程范例易于在多核上使用。

第一件事是，许多程序员避免编写好的、多读的应用程序，因此没有一批准备充分的开发人员，因为他们学习到的习惯会使他们的编码更难做。

但是，与大多数对cpu的更改一样，您可以查看如何更改编译器，并为此查看Scala、Haskell、Erlang和F#。

对于库，您可以通过MS查看并行框架扩展，这是一种使并发编程更容易的方法。

这是起作用的，但我最近有IEEE频谱或IEEE计算机有多核编程问题的文章，所以看看IEEE和ACM关于这些问题的文章，以获得更多关于正在研究的内容的想法。

我认为最大的障碍将是很难让程序员改变他们的语言，因为FP和OOP非常不同。

除了开发能够以这种方式工作的语言之外，还有一个值得研究的地方，就是如何处理访问内存的多个线程，但是，与这一领域的许多方面一样，Haskell似乎处于测试这方面想法的最前沿，所以您可以看看Haskell是怎么回事。

最终会出现新的语言，也许我们有DSL来帮助开发人员更多地抽象，但是如何教育程序员这一点将是一个挑战。

更新：

你可以找到第24章。兴趣的并发和多核编程，http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.html

Answer 2

我对这一领域的主要问题感到好奇，这些问题目前将阻止广泛采用编程技术和实践来充分利用多核体系结构的功能。

惯性。(顺便说一句:这几乎就是所有“是什么阻止了广泛采用”问题的答案，无论是并行编程、垃圾收集、类型安全还是节油汽车的模型)。

自20世纪60年代以来，我们就已经知道threads+locks模式已经从根本上打破了。到了1980年，我们已经有了十几个更好的模特。然而，现在使用的绝大多数语言(包括1980年以后从零开始创建的语言)只提供threads+locks。

Answer 3

其中一个答案提到了.NET框架的并行扩展，既然您提到了C#，我肯定会对它进行研究。微软在那里做了一些有趣的事情，尽管我认为他们的许多努力似乎更适合于C#中的语言增强，而不是一个单独的并发编程库。但我认为他们的努力值得称赞和尊重，因为我们来得早。(免责声明:大约3年前，我曾担任Visual的市场总监)

Intel的线程构建块也非常有趣(Intel最近发布了一个新版本，我很高兴下周到Intel开发者论坛了解更多关于如何正确使用它的信息)。

最后，我在西雅图的一家软件质量初创公司科法奇工作。我们有一个名为Jinx的工具，用于检测代码中的并发错误。一个为期30天的试用版可用于Windows和Linux，因此您可能需要查看它。(www.corensic.com)

简而言之，Jinx是一个非常薄的虚拟机监控程序，当激活它时，它会插入处理器和操作系统之间。然后，Jinx智能地获取执行片段，并运行各种线程时间的模拟，以查找bug。当我们找到会导致错误发生的特定线程计时时，我们会在您的计算机上使这个计时“成为现实”(例如，如果您使用的是Visual，调试器将在此时停止)。然后，我们指出代码中引起错误的区域。金克斯没有假阳性。当它检测到一个bug时，它肯定是一个bug。

Jinx可以在Linux和Windows上工作，并且可以在本地代码和托管代码中工作。它与语言和应用程序平台无关，可以使用现有的所有工具。

如果你检查它，请给我们反馈什么是有效的和不工作的。我们已经在一些大型开源项目上运行了Jinx，并且已经看到了这样的情况: Jinx发现big的速度比简单的压力测试代码快50-100倍。