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

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

首先,许多程序员都避免编写好的mulithreaded应用程序,因此没有足够多的开发人员做好充分准备,因为他们学到了一些习惯,这些习惯会使他们的编码变得更加困难。

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

这是在工作,但我最近无论是IEEE频谱或IEEE计算机有多核编程问题的文章,所以看看IEEE和ACM的文章已经写了这些问题,以获得更多的想法,因为什么是看。

我认为最大的障碍是很难让程序员改变他们的语言,因为FP与OOP有很大的不同。

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

更新:

你会发现 有趣的是, http://book.realworldhaskell.org/read/concurrent-and-multicore-programming.html

我很好奇这个领域中的主要问题,这些问题会阻碍广泛采用编程技术和实践来充分利用多核体系结构的能力。

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

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

英特尔线程构建块也非常有趣(英特尔最近发布了一个新版本,我很高兴下周能去英特尔开发者论坛了解更多如何正确使用它)。

最后,我在西雅图的一家软件质量初创公司Corensic工作。我们有一个名为Jinx的工具,专门用来检测代码中的并发错误。Windows和Linux有一个30天的试用版,所以你可能想看看。(www.corensic.com)

简言之,Jinx是一个非常薄的hypervisor,当激活时,它会滑入处理器和操作系统之间。然后,Jinx智能地获取执行片段,并运行各种线程计时的模拟以查找bug。当我们发现某个特定的线程计时会导致错误发生时,我们会在您的计算机上实现该计时(例如,如果您使用的是visualstudio,则调试器将在该点停止)。然后我们指出代码中导致错误的区域。有没有假阳性与厄运。当它检测到一个bug时,它肯定是一个bug。

Jinx可以在Linux和Windows上工作,也可以在本机代码和托管代码中工作。它与语言和应用程序平台无关,可以与所有现有工具一起使用。

设计用于高效利用多个处理器/内核的任何高性能应用程序(C或C++)的瓶颈是内存系统(高速缓存和RAM)。单核通常会使内存系统充满读写操作,因此很容易理解为什么添加额外的核和线程会导致应用程序运行较慢。如果一队人一次可以通过一扇门,那么增加额外的队伍不仅会堵塞门,而且会降低任何一个人通过门的效率。

我的经验是,高效的解决方案是所讨论的应用程序所独有的。通用准则(上面)是构建代码的基础,但是由分析结论产生的调整变化对于那些没有参与优化工作的人来说并不明显。

查找fork/join框架和窃取运行时的工作。相同或至少相关方法的两个名称,即递归地将大型任务细分为轻量级单元,以便利用所有可用的并行性,而不必事先知道有多少并行性。其思想是,它应该在单处理器上以串行速度运行,但在多核情况下获得线性加速比。

如果你看得对的话,这是一种水平的类似于缓存不经意的算法。