【转载】Free Lunch is Over(免费午饭已经结束了)

原文：Free Lunch is Over(免费午饭已经结束了)

 

微软C++大师Herb Sutter的文章《The Free Lunch Is Over》翻译，之前本身也常常翻译，可是都不会上传博客。我的很喜欢这篇文章，因此以此做为翻译生涯的开始。

 

免费的午饭结束了

软件并行计算的基本转折点

 

继OO以后软件发展的又一重大变革——并行计算

 

你的免费午饭即将即将结束。咱们能作什么？咱们又将作什么？

主要的处理器设计生产商，从Intel和AMD到SPARC和PowerPC，已经几乎穷尽了全部的传统方法来提升CPU性能。

他们专一于多线程和多核结构而再也不是提升时钟频率以及单指令流性能。这两个特性都已经应用于当今的芯片当中，

特别是，多核已经应用于当今的PowerPC和SPARC4代处理器中，2005年Intel和AMD也将引入这一技术。

事实上，2004年IN-Stat/MDR秋季处理器论坛的主题就是多核，而且许多公司都展现了新型的现代化的多核处理器。

回首往事，从称2004年为多核之年至今也没有很长时间。

 

多核使咱们在软件开发中至少在接下来几年内，在面向通用桌面电脑以及低端服务器应用方面带来重要的转折点（这刚好是当今软件销售的价值体现方面）。

在这篇文章里，我将详细描述硬件的变化、为何硬件会忽然影响软件发展以及并行计算如何影响你和你将来编写程序的方式。

咱们能够确信，免费的午饭已经完全结束一年或者两年了，只是咱们才刚刚认识到罢了。

 

免费的性能午饭

 

有一我的尽皆知的现象"Intel生产的，Gates都拿走了"。不管处理器运行的多么快，软件均可以找到一种方式耗尽额外的速率。

将CPU提升十倍的速率，软件一般会找到十倍的工做量运行（或者在某些状况写自由工做在十分之一的效率下）。

大多数应用在几十年内均可以得到免费规律的性能提高，甚至不须要发行新版本或作其余任何特殊的事情，由于CPU制造商（主要）和硬盘制造商（次要）拥有可靠的更新更快的主流系统。时钟频率不是衡量的惟一标准，甚至不是好性能的必要标准，但倒是有指导意义的标准：

咱们已经习惯看到500MHz的CPU被1GHz的替代，1GHz的被2GHz替代等等。今天主流电脑的主频能够达到3GHz的范围。

 

关键问题是：增加何时会结束？毕竟，虽然摩尔定律预言会发生指数级增加。可是当咱们到达硬件的极限时，显然指数级增加不能永远持续下去。

没有比光更快的事物，增加事实上必定会缓慢下来甚至中止。（注意：摩尔定律主要适用于晶体管集成度，可是在诸如时钟频率等其它领域指数级增加也会发生。

在其余方面甚至增加更快，最引人注意的是数据存储的爆炸性增加，但这一重要趋势适用于不一样文章。）

 

若是你是一个软件开发人员，你可能已经搭上了免费桌面电脑性能的列车。对于某些本地操做你的应用是否已经到达边界？

别担忧，传统的智慧离去，明天的处理器将拥有更大的吞吐量。不管如何今天的应用已经日益被诸如CPU吞吐量、存储速率等其余因素所抑制（他们常常与IO绑定，

与网络绑定，与数据库绑定）对吗？

 

在过去这些必定正确，可是在可预见的未来这一论断将会发生错误。

 

好消息是处理器将会继续变得强大。坏消息是，至少在短时间内，增加的主要方向将再也不是迎合当今多数应用的免费习惯之旅。

 

在过去三十年间，CPU设计师已经在三个主要方面得到了卓越成就，前两个关注与直线流指令执行：

1.时钟频率；

2.执行优化；

3.缓存。

 

增加的时钟频率意味着须要更多的时钟周期。提升CPU运行速率或多或少意味着作一样工做量会更快。

 

优化执行流程意味着每一个时钟周期作更多事情。今天的CPU运行一些功能更为强大的指令，它们优化的范围能够从外到内，

包括流水、分支预测、同一周期执行多条指令、甚至是从新排序指令执行流程。这些技术都是为了指令流更好或更快地执行，

而且经过减少延迟以及最大化单位时钟工做量来挤压每一个时钟周期作更多的事情。

 

芯片设计者承受愈来愈大的压力为了加速CPU运行速度，他们讲冒着改变甚至破坏程序意义的风险使它跑的更快。

 

除了简单的指令排序以及内存模型：请注意，我刚才所说的一些"优化"实际上以及不只仅是优化了，由于它们能够改变程序的意义

以及引发显而易见的影响，这些已经超出程序员的意料以外。但这却更有意义。CPU设计师通常都是健全和善的人们，他们一般不会想要伤害一只苍蝇甚至你的代码。

可是近几年，他们更愿意为了提升每周期运行速率将优化进行到极致，甚至明知这些侵略性的优化会影响到代码的原始语义。这是海德先生出现了吗？根本不是。

这种意愿只是简单地表示芯片设计师在提升CPU性能时所面对的极大压力。他们面对如此重的压力以致于他们为了提升运行速率愿意承担改变代码愿意甚至破坏代码功能

的风险。在读写代码从新排序方面，有两个格外值得注意的例子：容许处理器对写操做进行从新排序后果如此不堪设想以致于这个功能必须被关闭由于当对程序进行任意

的写操做排序后很难了解程序的真正含义。对读操做的从新排序也会带来惊人的明显影响。可是通常它会颇有效由于它对程序员而言不难么苦难。而且对于高性能的操做

系统和操做环境的需求为程序员带来极大的负担，由于放弃优化的机会被视为更加愚蠢。最终，设计师将cache与RAM分离并增长它的容量。

主存依旧比CPU慢，所以将须要将它放在离CPU更近的地方，可是却没法比片上缓存更加接近。今天，片上缓存的大小已经飙升，主要的芯片上以2MB或更多的二级缓存芯片

为主。（在这三种史上提升芯片性能的方法中，增长缓存将是惟一将在短时间内仍旧持续有效的方法。稍后我会浅析缓存的重要性。）

 

好了，如上所述，这意味着什么？

 

首先要认可一件重要的事情就是这一系列事情都与并行计算无关。在这些方面进行加速将直接致使顺序程序（非并行、单线程、单处理器）以及并发程序的加速。

这很重要，由于当今的不少主要程序都是单线程的，这也便于我深入的开展话题。

 

固然，编译器也不得不跟上发展水平。有时，为了使用新指令（如MMX、SSE）维护CPU的最优效能你须要从新编译应用。

可是，一般老的应用甚至在没有利用处理器新指令和新特性的前提先，不须要从新编译也能够运行得更快。

 

世界本事一个好地方，可是不幸的是，它却消失了。

 

障碍，今天为何没法生产10GHz的芯片？

 

                                   图 1 Intel处理器介绍(来自维基百科Intel)

 

CPU性能的增加早在两年前就已经遇到瓶颈。多数人却在最近才开始注意到。你能够用其余架构的芯片做为对比，这里我仅仅以Intel为例。图一表示历史上Intel处理器的主频以及晶体管集成度的参数。晶体管的集成度至少如今仍然在增加。可是主频则不一样。

 

从2003年开始，你会注意到一个由当前趋势向更快速率发展的拐点。我增长了一条基准线显示最大时钟频率的极限趋势。再也不是持续的增加走向，取而代之的是忽然的平缓趋势。提升CPU主频变得愈来愈困难，由于这不只仅是一个而是几个物理问题形成，特别是热、功耗过大、当前的电流泄露问题。

 

要点：你的工做站的CPU主频是多少？工做在10GHz吗？对于Intel的芯片，很长时间以前咱们就能够达到2GHz（2001年8月），根据2003年的趋势，在2005年初咱们就应该研发出10GHz的芯片。其实，咱们根本没有作到。咱们甚至怀疑是否会看到10GHz芯片的出现。

 

嗯，那么4GHz呢？咱们已经实现3.4GHz了，4GHz还会远吗？唉，事实上4GHz彷佛也很遥远。2004年中叶，你可能也知道，Intel首次推迟它的4GHz芯片直到2005年，在2004年秋天，官方正式彻底放弃4GHz芯片计划。在撰写本文之际，Intel计划在2005年初能够稍微提升主频到3.75GHz，但至少对于如今来说，几乎很难实现；Intel和和大多数处理器厂商的将来在于多核这一相同方向。

 

终有一天咱们会在主流的台式机上采用4GHz的芯片，但这一天必定在2005年以后。固然，Intel也拥有在实验室能够更高速运行的样品，但却须要更多的配件，诸如大量的冷却设备。在未来的某一天你的办公室也不会配备那样的设备，或者当你在飞机上使用电脑时没法放置在你的腿上。

 

摩尔定律和下一代

世界上没有免费的午饭。——R. A. Heinlein

 

这是否意味着摩尔定律结束了？有趣的是，答案每每是否认的。固然，像指数级增加，摩尔定律终有一天会结束，但这彷佛要等到若干年以后。尽管芯片设计师在时钟周期方面已经遇到瓶颈，可是晶体管的数量仍旧日益膨胀，CPU也貌似继续遵循摩尔定律在将来几年日益增长吞吐量。

 

关键的区别，这也是本文的核心，在于性能的提高在至少下一代代电脑中将以不一样的方式实现。而且当前最新的应用也不会再由于没有大规模的从新设计和受益。

在不久的未来，也就是接下来的几年内，新型芯片性能的提高将主要依靠三种主要的方式，只有其中的一种是过去的方式。短时间内性能的提高将由下列因素所驱动：

超线程

多核

缓存

超线程是关于在单一处理器中并行地运行两个或更多个线程。超线程在今天已经被应用，同时容许多条指令并行执行。一个限制因素是，超线程须要更多的硬件开销，包括额外的寄存器。它仍然只有一级缓存、一个整数运算单元、一个浮点运算单元等单处理器的特性。超线程有时在合理编写超线程应用时被称为能够提升5%到15%的性能，甚至在理想条件下能够达到40%的性能提升。这已经很好了，但仍然没有提升一倍性能，而且对于单线程应用没有任何用处。

 

神话与现实：2*3GHz < 6GHz

 

一个由双核组成的CPU实际上提供了6GHz的处理能力，是吗？

显然不是。甚至在两个处理器上同时运行两个线程也不见得能够得到两倍的性能。类似的，大多数多线程的应用不会比双核处理器的两倍快。他们应该比单核处理器运行的快，可是性能毕竟不是线性增加。

 

为何没法作到呢？首先，为了保证缓存一致性以及其余握手协议须要运行时间开销。在今天，双核或者四核机器在多线程应用方面，其性能不见得的是单核机器的两倍或者四倍。这一问题一直伴随CPU发展至今。

 

其次，除非双核运行不一样的进程，或者同一进程的不一样线程能够独立运行，而且历来不须要等待其余进程或线程，他们才可能被高效利用。尽管如此，我仍旧能够推测今天运行在双核芯片上的单核应用也能够看到显著的效率提升，不是由于额外的核心实际在作有价值的工做，而是那些能够减慢单核机器运行速度的广告插件和间谍软件。你以为将其中一个处理器留给间谍软件是解决问题的方案吗？

 

若是你正在运行一个单线程的应用，那么该应用将仅仅使用一个核心。应该有必定的加速比由于操做系统和应用能够运行在不一样的核心。可是操做系统每每不会耗尽一个核心的利用率而致使其中一个核心每每空闲。（一样的，间谍软件业能够占据操做系统的大部分空闲时间。）

 

多核其实是指在同一个芯片搭建两个或者更多个核心。一些芯片，包括SPARC和PowerPC，已经拥有成功的多核版本。2005年Intel和AMD的早期产品，功能类似只是集成度略有不一样。AMD彷佛有一些初步性能设计的优点，好比在同一芯片上具备更好的集成度。而Intel的初始方案几乎是将两个Xeon处理器放置于同一个芯片上。性能的提高应该如同有两个真是的双CPU系统通常（仅仅是系统将更便宜由于母版有两个插槽），这也意味着速度的提高将小于一倍，就像今天这将促进写多线程应用同样，而再也不是单线程应用。

 

最后，片上缓存的大小预计至少在短时间内将继续增加。在这三点中，只有这一点将使大多数的现今应用受益。持续增加的片上缓存的大小将对应用程序很是重要且有益处，仅仅是由于空间即速度。内存访问的开销太大，若是有可能你愿意尽可能避免访问RAM。在当今的系统，高速缓存未命中而去访问内存的开销通常是访问缓存开销的10倍到50倍。这一点，让人们很惊讶，由于内存访问与外存和网络访问相比要快不少，可是却不能与访问速度最快的缓存相提并论。若是某个应用能够利用缓存的这一特性，那么咱们就真正利用了多核，不然咱们则没有。这就是为何在近几年内经过增长缓存大小而不须要大规模从新设计也能够提升不少应用的运行效率。随着愈来愈多的应用程序处理大量的数据，并为它们增长若干代码以适应新的特性，性能至上的操做须要适应缓存的这一特性。就好像大萧条时期的员工在提醒你，“缓存才是王道”。

 

(旁白：这是一件最近发生在个人编译器团队身上的事情，偏偏证实了“空间即速度”。编译器使用相同的资源为32位和64位进行编译，程序仅仅是被选择编译成32位仍是64位。运行在64位机器上的64位编译器得到了大量的基准性能，原则上是由于64位处理器拥有更多的64位寄存器协同工做以及其余编程特性。一切都很好，可是数据大小呢？升级到64位并无改变存储器中的大部分数据，只是一部分指针大小变为原来的两倍。当这件事情发生的时候，相对于其余的应用来讲，咱们的编译器使用了更加繁琐的内部数据结构。由于指针如今是8个字节而再也不是4个字节大小，这显然增长了数据大小，在64位工做机制下，咱们的编译器在数据大小方面增长显著。更大的工做集几乎抵消了由更快的处理器与更多寄存器协同工做带来的性能提升。在撰写此文之际，64位编译器与32位编译器性能几乎相同。尽管对二者而言资源相同，64位编译器仍旧提供了更大吞吐量。空间即速度。)

 

可是缓存就是这样。超线程和多核的处理器对当今大部分应用程序则没有影响。

 

那么，硬件中的这些改变又怎样改变咱们编写软件的方式。目前为止你可能已经看到了一些基本的答案，让咱们深刻研究它以及它带来的影响。

 

对于软件的意义：下一场革命

 

在20世纪90年代，咱们就学会了面向对象的思想。在过去20年里，也能够说在过去30年间，在编程领域从主流的结构化编程到面向对象发生了巨大的变革。或许还有其余的改变，好比最近兴起的web编程，可是咱们大多数在一辈子中都很难看到对软件革命如此重要和深远的改变。

 

直到如今。

 

从今天开始，性能将不会再白白提高。固然，仍旧存在任何人均可以使用的性能提高的途径，这主要归功于高速缓存大小的提高。可是若是你想要你的应用程序重新型处理器的指数级增加的吞吐量中得到提高，就须要精心编写并行一般是多线程的应用。提及来容易作起来难，由于并非全部的程序在本质上说都是并行的而且并行计算很苦难。我时常能够听到一些抗议的报道：“并行计算，这并不算是新闻，人们已经开始编写并行计算的应用。”一小部分开发者确实如此。

 

请记住在20世纪60年代中后期，人们使用Simula语言进行面向对象编程，可是直到20世纪90年代面向对象才在主流编程语言中引起一场革新。为何？革新的主要缘由是咱们的产业被编写愈来愈大的系统、解决愈来愈多的问题、利用CPU以及存储资源所驱动。面向对象的抽象及独立性使得大型软件的发展更有收益、更可靠及可重用。

 

一样的，自从黑暗时代咱们就开始进行并行编程，编写例程、检测系统以及相似爵士乐的东西。在过去的十年间，咱们已经目击了愈来愈多的程序员编写多线程、多进程的并行系统。可是这场变革伴随着一个重要的转折点——并行计算的实现变得缓慢。今天绝大多数的应用都是基于单线程的，在下一节我将叙述一些好理由。

 

顺便说一下，关于炒做的问题：对于他们的新技术人们老是很快宣布这是将来软件发展的革命。不要相信它，新技术每每真正有趣有时有益处，可是这些年中咱们从编写软件中得到的巨大革新已经经历了逐步增加过渡到爆炸性增加的阶段。这些是必要的的：你仅仅只能在一个很成熟的技术定义软件发展的变革，包括稳定的供应商和工具支持，至少在七年前没有稳定的性能和致命性缺陷前一般采用各类新的软件技术。做为这样一个结果，真正的如面向对象的软件革新在多年前就已经具备一些优化技术，每每是在十多年前。即便在好莱坞，最真实的“一晚上成名”在得到大突破前也须要由不少年的表演经验。

并行计算是编写程序的下一个重大变革。不一样专家仍旧对它的影响是否比面向对象更大持有不一样见解，固然这样的话题最好仍是留给专家。对于技术人员而言，并行计算与面向对象在复杂度和学习曲线上处于同等地位。

 

并行计算的益处和成本

 

并行计算，特别是多线程已经在主流软件中被应用有两个重要缘由。首先上，逻辑上具备独立的控制流；例如，我设计的一个数据库复制服务程序中，很天然的将每个复制会话放在本身的线程内实现，由于每一个会话彻底独立不须要其它会话也能够被激活（只要他们不工做在同一数据库区域）。另外一个颇不常见的缘由是编写并行程序能够提升性能，要么利用多个处理器的性能或者容易减小程序其余部分的延迟。在个人数据库复制服务程序中，该因素也体现的淋漓尽致，分卡的线程充分利用了多个处理器的性能由于咱们的服务器可与其它服务器一块儿并行计算更多的应用程序。

 

然而，并行计算的开销却很大。某些明显的成本相对不那么重要。好比，锁的开销很大，可是若是你能找到一种合理地方式并行化操做而且减小或消除共享状态，那么当你使用正确明智时，你会得到不少性能的提高。

 

可能第二大的成本是并非全部的应用程序都适合并行化。这点稍后我会进行讨论

 

最大的成本多是并行化的使用难度：程序模型，即程序员头脑中的模型，与顺序的控制流相比，程序员须要对使用并行化编程有着合理的理由。

 

每个认为本身理解并行计算的人们，最终将发现本身并无真正理解并行计算。随着程序员学会对能否并行提出疑问，他们发现这些答案一般在内部测试中被发现，他们从而达到了一个新的理解程度。那么一般不会在测试中发现的每每是:理解为何和怎样作压力测试？这些是否只是停留在多处理系统表面的并行问题？在单处理器系统上线程将在哪些地方进行切换？他们是否真的同步执行而不产生任何错误？这是人们认为他们了解编写并行程序的心里疑惑阶段：我曾遇到过不少团队在压力和扩展测试下应用效果不错，在许多我的网站运行的也很良好，可是直到真的应用到拥有多处理器的环境下，程序出现间歇性的崩溃。

 

在当今处理器发展前景下，为了在多核机器上运行多线程程序而从新设计编写应用有点儿像经过直接跳入最深的泳池学习游泳，真正的并行环境更容易暴露程序设计中的错误。即便你拥有一个可以可靠编写并行程序的团队，也还会有其余缺陷；好比，并行程序是彻底正确的可是没有单核机器运行的迅速，特别是在线程并不能足够独立而且共享程序执行所需的单一资源时。此时，状况变得很微妙。

 

今天绝大多数程序员都没有真正领会并行计算的真谛，就像15年前大多数程序员尚未领略面向对象的真谛同样。

 

与从结构化编程到面向对象编程是个飞跃同样（什么是对象？什么是虚拟的功能？我应该如何使用继承？除了“什么”以及“如何”外，为何正确的设计实践是正确的？），从顺序编程到并行编程一样也是一个飞跃（什么是空转？什么是死锁？它是如何产生，又该如何避免？什么样的结构致使我认为是并行化的程序其实是串行化。除了“什么”以及“如何”外，为何正确的设计实践是正确的？）。

 

今天绝大多数程序员都没有真正领会并行计算的真谛，就像15年前大多数程序员尚未领略面向对象的真谛同样。可是并行化编程是能够学习的，特别是咱们坚持以消息和锁为基础进行编程，而且一旦领略它，其实它并不比面向对象困难并且使用起来很天然。你只须要为你和你的团队准备足够的时间进行训练。

 

（在上面的并行化编程模型中我故意强调基于消息和锁，也有一种无锁编程，至少被Java5和一种流行C++编译器支持。可是对于程序员来讲无锁编程要比基于锁的编程可贵多。大部分时间里，只有系统和库的编写者不得不须要了解无锁编程，尽管几乎每一个人都须要利用系统函数和库函数。坦白讲，即便是基于锁的编程也是有风险的。）

 

对咱们意味着什么

 

好吧，回到“对咱们意味着什么”这一话题。

1.咱们已经了解到了明确的主要后果：若是咱们想要充分利用以及有效提高的CPU吞吐量，更多的应用程序须要而且在接下来几年会采用并行化编程的方式。例如，Intel正在谈论在未来的某一天研发具备100个核心的芯片，单线程的应用至少能够利用1%的潜在吞吐量。“喔，性能并不那么重要，计算机在变的愈来愈快”的言论保守怀疑，在不久的未来，这几乎是错误的。

 

更多的应用须要并行化若是想要彻底利用持续指数级增加的CPU吞吐量。效率和性能的提升将会变得更多，而不是更少，这很重要。

 

如今，并非全部的应用（或者更精确的说，应用的重要操做）适用于并行化。事实上，一些问题，好比编译，是理想的并行化应用。可是其它的并非，一个经典的例子是不能仅仅由于一个妇女须要花费9个月时间产下一个婴儿，就意味着九个妇女能够在1个月内产下一个婴儿。在此以前你也可能碰到过相似的状况。可是你有主要到这些现象所引起的问题吗？这些是回答相似问题的答案：你为何认为这个婴儿问题本质上不能并行化？一般人们错误的引用这些类似的状况证实不能并行化的问题，但事实上不必正确。若是目标是产下一个婴儿，这事实上是一个非并行化问题。若是目标是产下多个婴儿，这其实是一个并行化问题。了解实际的目标能够是事情变得大不相同。在软件研发中，当你考虑是否或如何并行化时，你须要谨记这个以目标为基础的准则。

 

2.可能较不明显的影响是应用与CPU的结合变得愈来愈紧密。固然，并非全部的应用都如此，甚至是若是没有准备充分就没法与CPU紧密结合，可是貌似咱们已经到达了“应用于I/O结合、与网络结合、与数据库结合”增加趋势的尽头，由于性能在那些领域的提高依然迅速可是传统的CPU性能提高技术却已通过时。考虑下面这一状况：如今咱们停滞在3GHz的范围内。所以，对于单线程应用，除非利用增加的高速缓存大小（这是主要的好消息），彷佛再也没法提高运行速度。其它的获利彷佛比咱们过去经常见到的少不少，例如芯片设计师找到新的方式保证流水线满而避免停滞，这一领域收获颇丰。新的应用特性并无减小，甚至解决大量应用程序数据增加的须要也没有中止。随着咱们期待程序能够作更多的程序，除非他们采用并行化编程他们才能够完全榨干CPU的每一点资源。

 

有两种方法解决并行化带来的改变。其中之一是如上所述，使用并行化从新设计你的应用程序。另外一种相对简单，写更有效的程序浪费更少的资源。这致使了第三种结果：

 

3. 效率和性能的提升将会变得更多，而不是更少，这很重要。那些具有深入优化的语言重获新生，他们不须要找到竞争变得更有效、更优化的方式。人们将一直期待以性能为宗旨的语言和系统。

 

4．最后，程序预压及系统将逐渐被迫解决并行化问题。尽管为了编写更有效更正确的并行化程序，不少错误在后来的版本才被修正，Java在最初的版本就已经支持并行化。长期以来，C++也被用来编写具有多线程应用的系统，可是一直没有支持并行化的标准（ISO C++标准甚至没有明确的提到线程），而且典型的并行程序须要由具有与平台无关的特性和库文件。（这一般是不彻底的，好比，静态变量必定只能被初始化一次，这须要由编译器用锁包括，可是许多编译器并不产生这样的锁。）最终，产生一些并行计算的标准，包括Pthread和OpenMP，一块儿其余的明确支持并行化的标准。使用编译器检查你的单线程应用程序以判断如何使它并行化是很是好的思路，可是自动的转换工具仍旧有一些限制，而且并不受你本身的代码控制。主流的基于锁的编程艺术，很微妙也颇有风险。咱们急切须要一个比当今语言更高效的并行化语言模型。一下子我将谈及这点。

结论 

若是你此前没有作过，如今是时候你从新审视你的应用，决定哪些操做时CPU敏感型的以决定在那些地方是否可使用并行计算。如今对于你和你的团队也是时候领略并行编程的徐需求、诱惑、风格和用法。不多一些应用天生适用于并行化，但大多数并非这样。甚至当你确切了解到哪些是CPU紧密型时，你也会发现将那些操做并行化很是困难。全部开始学习并行计算的缘由是并行计算是软件开发的下一次变革。并行编译器能够起到一些做用，可是不要过度期待。他们永远没法与你经过明确的并行化以及多线程使串行程序并行化的程度相提并论。

 

感谢高速缓存大小的增加以及指令控制流的优化，免费的午饭还会延续一段时间；可是如今开始提供的东西将会少不少。吞吐量的增加仍旧持续，可是须要额外的研发精力、额外的代码复杂性、额外的测试精力。好消息是不少类应用的额外努力是值得的，由于并行化将使得它们继续利用处理器吞吐量的指数级增加的优点。