毋庸置疑的是:多核计算机已经成为现实。
同样不可置疑的是:高效的多核编程相当困难。这不仅仅是了解pthread的问题。
对于“街头开发者”是否需要关注这些发展还有争议。
你对于必须扩展多核技能感到担忧吗?你所编写的软件是否适合并行化,如果适合,你是否正在学习相关技术(如果你之前不知道这些技术)?或者你认为操作系统会处理大部分事情,语言运行时也会尽其所能,你的应用程序愉快地在一个核上运行,让其他核去做它们的工作?
毋庸置疑的是:多核计算机已经成为现实。
同样不可置疑的是:高效的多核编程相当困难。这不仅仅是了解pthread的问题。
对于“街头开发者”是否需要关注这些发展还有争议。
你对于必须扩展多核技能感到担忧吗?你所编写的软件是否适合并行化,如果适合,你是否正在学习相关技术(如果你之前不知道这些技术)?或者你认为操作系统会处理大部分事情,语言运行时也会尽其所能,你的应用程序愉快地在一个核上运行,让其他核去做它们的工作?
你的程序通常是CPU密集型的吗?
如果不是,那就不用管它了。这与你无关,并且可以使你的用户获得更流畅的体验而不对你造成任何要求。
很酷,对吧?
如果你的程序是CPU密集型的,并且你的问题可以并行处理,那么你可能可以利用多个核心。那就是开始担心的时候了。
来自评论:
改进答案的建议:大概解释如何判断你的程序是否是CPU密集型。 - Earwicker
CPU密集型意味着阻止程序运行更快的事情是缺乏计算能力。与IO密集型(或有时称为网络密集型)相比较。不良的主板和处理器选择也可能导致机器内存密集型(是的,我在看你,Alpha)。
因此,你需要知道你的程序从一刻到另一刻在做什么(以及机器的繁忙程度...)。要在类Unix系统上找出,请运行top
命令。在Windows上,请使用任务管理器(感谢Roboprog)。
在负载小于每个核心1的机器上(也就是你不做什么的桌面机器),CPU密集型进程将始终占用超过50%的处理器(通常超过90%)。当负载平均值高于此时(例如,你有三个编译器、SETI@home和两个点对点网络在后台运行时),CPU密集型进程将占用大部分(# of cores)/(load average)
。
顺便提一下:如果你的应用程序具有图形用户界面(GUI)且需要进行大量计算,请始终在单独的线程上进行强制性计算。忘记这样做是GUI冻结的原因。
我不同意目前被接受的答案。
多核机器最重要的方面是CPU和主存储器相距很远。这意味着,除非应用程序是"尴尬地并行"或易于并行化,否则它很可能会成为内存绑定而不是CPU绑定。浮点数乘法需要约4个时钟周期,而从主存储器中获取数据需要数百个时钟周期。因此,利用缓存局部性变得很重要。
对于难以并行化的应用程序,如果单核心实现的性能足够好(大多数应用程序属于这一类),则无需并行化。但是,如果单核心性能不够好(或者你的竞争对手的应用程序在并行化方面更具响应性),那么你最好重构你的应用程序以更好地利用并行性和缓存局部性。笼统地说,重构后的应用程序将由相对独立(或者通信较少)的子模块组成,这些子模块可以并行运行(请参见此示例)。
请参见http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-183.html,了解多核和事物发展的良好概述。他们提到的主要观点是:
这是一个开始学习函数式语言的好理由,因为它们更容易优化并行执行。
我认为这个话题非常值得关注,姑且这么说吧。
过去几十年中CPU速度的巨大提升无疑非常有价值,而未来的进一步提升同样有价值。
但是,未来的提升主要将由核心数量的正常加倍组成。因此,为了从这些提升中受益,软件需要具备可并行性。
许多应用程序中计算密集型的部分实际上是使用SQL编写的,因此它们已经具备了被RDBMS分解为并行任务的功能。所以那些人可以放心了。
但是,对于我们大多数使用C#编写GUI的人来说,即使我们在编写GUI,也需要密切关注这方面的内容。GUI通常需要对其呈现给用户的模型执行某些有用的操作,当用户必须坐等完成时,他们会感到恼怒。在未来几年中,当他们查看任务管理器并发现他们新购买的32核机器仅利用了约3%时,他们甚至会更加恼怒。
我认为这是一个很好的问题。因此,我开始写了一系列关于它的博客文章在这里。
Dmckee的回答在最狭义的意义上是正确的。让我用自己的话重新表述一下,隐含地包括一些评论:
对于不受CPU限制的操作,并行化没有任何价值。对于仅在短时间内(比如少于几百毫秒)受到CPU限制的操作,并行化的价值很小。实际上,这样做很可能会使程序更加复杂和有错误。学习如何实现细粒度并行性是复杂的,而且做好这件事是困难的。
就其所及之处而言,这是正确的,但我认为对于更广泛的程序集合来说,答案更加丰富。实际上,在生产应用程序中使用多线程技术和隐式的多核技术有很多好处。例如,将磁盘和网络I/O操作移出用户界面线程对用户非常有益。
这与增加计算操作的吞吐量无关,而是与保持程序用户界面的响应性有关。请注意,这里不需要图形用户界面 - 命令行程序、服务和基于服务器的应用程序也可以从中受益。我已经使用线程编程超过15年了。我一点也不担心。