Barroso是Google公司的首席工程师，并且领导该公司的平台工程小组。他曾经为Google的系统基础设施做出过多方面的贡献，其中包括负载平衡、错误探测及恢复、通讯库、性能优化和计算平台设计。在加盟Google之前，他曾经在Compaq和DEC公司承担研究工作，主要研究商业工作负荷的处理器和内存系统架构，并且与他人合作设计出Piranha系统。Barroso拥有南卡罗来纳大学计算机工程博士学位，以及巴西里约热内卢PUC大学的电气工程学士及硕士学位。
芯片多处理技术的经济性因素：成本
在1990年底，越来越多的小组都倡议使用CMP（芯片多处理技术）来替代复杂性较高的单线程CPU，而我们的DEC研究小组正是其中的一个。我们当时正在设计Piranha系统，1 这种系统在当时的CMP设计领域绝对是一种超前设计，因为我们使用了非常简单的核心（类似80年代末的早期RISC设计），并利用它来提高更高水平的线程级并行处理能力。我们的主要目标是利用有限的芯片预算来实现最佳的商业工作负荷性能。
今天，在开发Google的计算基础设施过程中，我们的焦点已经变得更加广泛，超越了简单的性能问题。为了评价某个特定架构的优劣，我们首先必须回答下列的问题：对于您所需要的计算能力，您在经济上是否能够承受？Google的多数服务所提出的计算需求都非常高，因此我们必须首先开发出一套思路，深入理解计算的总体成本，并且不断地寻找合适的硬件/软件设计来优化每个成本单位的性能。
本文探讨的正是大规模服务基础设施中的各类成本趋势，并且重点了基于CMP系统在改善整体计算平台费效比的过程中所面临的各种机遇与挑战。
理解系统成本
系统设计界已经开发出了体系完备的各类工具，能够对性能进行全面的测量、建模、预测和优化。然而，这一领域对成本因素的理解与认识仍然处于初级阶段。如果对成本的问题没有全面的考虑和理解，那么任何一种技术或产品的优势都无从谈起，而且也不可能得到验证。
我们可以将一个大规模计算群集的TCO（总体拥有成本）分解为四个主要的组件：硬件的价格、能源消耗（数据中心的初始和后续投资）、数据中心的后续运营成本，以及软件基础设施的成本。在商业性部署中，通常最主要的TCO组件就是软件。如果我们将TPC-C基准档案中使用的系统价格进行粗略的分解，我们就会发现，每个CPU的成本中，操作系统和数据库引擎的成本约为4000至20000美元。2如果算上其它操作系统组件、应用和管理软件的授权费用，相对来说其它组件的成本变得几乎不值一提。如果在部署过程中使用的是中档和低端服务器，那么这种情况就会变得更加明显。由于这类部署中的廉价服务器数量众多，但却会导致软件成本的上升，因为按CPU或按服务器数量确定授权费用的策略目前仍然是一种非常流行的作法。
Google选择的作法是，将软件基础设施的生产保留在公司内部，并且与开放源代码社团进行合作，通过这种方式来降低软件的成本，从而改变这种成本分布的局面。虽然软件开发成本仍然存在，但在大型CPU部署中这种成本已经被分散开来。因此，Google就需要对剩留的那些组件特别留意。下面，我们将集中讨论那些更有可能对成本组件产生直接影响的系统设计选择：硬件和能耗成本。
screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.style.cursor='hand'; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onclick="if(!this.resized) {return true;} else {window.open('http://storage.msn.com/x1pC-7nLWDVofTg8sYJjhV23GCUTmiowgw-S2-iSHIfmqZkS3eqc1ZaOt_Z4HPPx7wgCVu1Ads4JGBse_Bn9ftjMrBdXk2IJBeVLkXzmZB_kBU');}" src="http://storage.msn.com/x1pC-7nLWDVofTg8sYJjhV23GCUTmiowgw-S2-iSHIfmqZkS3eqc1ZaOt_Z4HPPx7wgCVu1Ads4JGBse_Bn9ftjMrBdXk2IJBeVLkXzmZB_kBU" onload="if(this.widthscreen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" border=0screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.style.cursor='hand'; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onclick="if(!this.resized) {return true;} else {window.open('http://storage.msn.com/x1pC-7nLWDVofTg8sYJjhV23KUZEgBZwRQ6qGoWw3pCnzY2nAhM_sYjVPOvv-Ty7oYni7cv5KY-qBXOV8Z3EOlvm2jVYOcabnbp8MCS9wq8eJo');}" src="http://storage.msn.com/x1pC-7nLWDVofTg8sYJjhV23KUZEgBZwRQ6qGoWw3pCnzY2nAhM_sYjVPOvv-Ty7oYni7cv5KY-qBXOV8Z3EOlvm2jVYOcabnbp8MCS9wq8eJo" onload="if(this.widthscreen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" border=0
HG1表示的是连续三代Google服务器平台的性能、单位服务器价格性能比和性能功率比趋势。Google的硬件解决方案中也包括低端服务器的使用。这些系统是基于数量巨大的PC级组件，因此各代的系统都能够以基本相同的成本提供逐步提高的性能，从而产生了单位服务器价格性能比曲线的逐步上升。另外， Google的容错软件设计方法也使这些可靠性相对较低的系统组件能够提供可用性很高的服务。
然而，功率性能比却呈现出一种浮动的趋势，虽然人们已经采用了很多方法，努力在设计中提高单位功率下的性能，但这种效果似乎并不明显。换句话来说，每一次性能的提升都伴随着成比例增长的总体平台功率消耗。因此，在总体拥有成本中，与功率有关的成本一直呈现增长的趋势。这些趋势会对计算成本产生重大的影响。下面的分析中忽略了其它间接的功率成本，将注意力完全集中在能源成本方面。今天，基于典型低端x86处理器的服务器成本约为3000美元，平均功耗为200瓦（峰值功耗可以达到300瓦）。通常情况下，由于无效率工作时间和制冷所消耗功率通常会使能源成本预算翻倍。如果我们假设基本的能源成本为9美分/瓦小时且服务器的寿命周期为4年，那么在今天，该系统的能源成本已经占到了硬件成本中的40%。
更糟糕的事情还在后头。如果单位功率性能在接下来的几年中保持连贯性，那么功率成本将会很容易地超过硬件成本，而且很可能会超出很多。HG2描绘的便是这种推演的结果。我们在其中假设会出现四种不同的年度性能及功率增长率。对于最为极端的情形（年增长率达到50%），在十年使用周期即将结束时，服务器的价格将只占很小的一部分。但需要注意的是，这个推论中并没有考虑能源成本在未来几年中可能出现的增长。在这种极端的情况中，机器所消耗的功率成本比机器本身的成本要多得多。也许我们可以设想，有一天供电企业会创造出一种奇怪的商业模型：如果企业愿意与其签订长期的供电合同，这些供电企业将免费向企业提供硬件。
计算机设备功耗失去控制的可能性很可能对计算的总体经济性产生巨大的影响，当然对地球总体环境的不良影响也是显而易见的。需要注意的是，尽管从全局来看 CPU所消耗的功率只占整体系统功耗预算中很小的一部分，但在低端服务器平台上，这类功耗所占的比率很可能会高达50%至60%。
效率CMP和计算效率
为了避免出现上面设想的那种可怕未来，我们有必要对采用CMP技术的处理器进行全面的介绍，而且充分了解这方面的情况将是避免出现不良后果的最佳（很有可能是惟一的）途径。正如我们在本期第一篇文章（“多处理器的未来”，作者：Kunle Olukotun和Lance Hammond）中所讨论过的，如果我们能够利用线程级并行技术，能够通过增加晶体管的数量并提高能源预算，我们完全可以增加核心的数量，从而更有效地提高性能。这种性能提高是其它任何已知技术所无法比拟的。在这种多线程环境中，预测和推测技术必须极为精确，只有这样，额外的功率和不动产投资才会显得物有所值，因为其它线程都准备执行非预测性的指令。但不幸的是，许多服务器级的工作负荷所表现出的指令级并行能力都是相当差的，4 因此，它们很难适应今天那些常见的预测性乱序核心。
Google的一些关键工作负荷就包含此类的行为。例如，我们的索引服务应用在新型处理器上每两个CPU周期里平均只收回一条指令，对多个发起槽（issue slot）和可用功能单元的利用率很低。导致这种现象的原因是索引服务应用所使用的数据结构太大，处理器芯片上的缓存无法处理，而且与数据关联的控制流程会将管线暴露给较大的DRAM延迟。这类行为还会导致内存系统的利用率过低，因为在上一个内存访问不可用时新的内存访问不可能发出。在控制流程和内存访问流中也存在足够的不可预测性，这就使得预测技术相对失效。然而，如果采用的是传统的多处理器、并发多线程系统和CMP5，那么同一工作负荷的级程级速度会发生很明显的提升。
在Piranha的实施过程中充分借鉴了商用工作负荷行为的教训：如果有足够的（硬件和软件）线程，我们就根本不需要去预测。它所采用的8个CPU核心事实上是早期RISC设计的一次再生：单发起、顺序、非预测性。第一颗Piranha芯片将比其它最新CPU的性能高出两倍以上，而功耗只有后者的差不多一半。这一点非常重要，因为我们的小组在设计时完全忽略了功率效率，没有将其作为一个设计目标，但却得这样的成绩确实让人感到激动。这可以算是一个非常好的例证，充分说明CMP模型与生俱来的功率效率优势。
最近，一些厂商都发布了新的产品，这些产品可以帮助我们深入了解CMP微架构的功率效率潜力。AMD和英特尔都推出了CMP设计，其功率包线与上一代的单核心产品基本相同。例如，AMD报告称，根据一系列的基准测试6，其双核心Opteron 275型处理器的性能比对等的单核心处理器（Opteron 248）要高出约1.8倍，而功率包线的增长幅度不超过7%。即使我们悲观地假设整个平台的功率增长幅度相同，双核心平台的功率效率（单位功率性能）仍然比单核心平台提高了近 70%。的确，在确实这些进步的过程中，进程技术方面的改进扮演了非常重要的角色，但事实是，人们第一次开始重视处理器的功率效率，并试图寻找合适的方法来大幅改善这方面的性能。
缓慢的步伐
在我们于2000年发表的第一份Piranha报告中，我们将芯片多处理技术看作微架构演化中的必然趋势。尽管在这方面已经不存在任何的争议，但这种观点用了这么长的时间才被人们广泛地接受，这一点让人感到多少有些惊讶。尤其让我感到惊讶的是，像Piranha这类更为激进的CMP架构牺牲了单线程性能来换取线程级的并行能力，而这类技术的商用产品7 直到时近才出现，而且很可能要花很长的时间才能正式上市销售。
CMP商用产品的推出过程似乎遵循的是一种更有规则的方式，即随着晶体管预算的增加，较为复杂的核心被逐步添加到新一代的芯片上。如果CMP的前景如此诱人，为什么要用这么长的时间才让它的潜力变成现实呢？这里面的主要原因有四个：
功率包线。事实证明，与我们在Piranha开发过程中的构想正好相反，仅凭设计的复杂性和性能并不足以促使人们转而采用CMP架构。功率才是真正的原因。为了避免采用昂贵的冷却技术，芯片开发商们不得不坚守在功率密度的边界之内，而要想利用传统的技术来实现这一目标已经变得越来越困难。
市场因素。兆赫兹是一个非常容易理解的性能参数，厂商利用它也更容易说服消费者。尽管它只是一种很差的应用性能指标，但多数常用基准测试中所用到的参数也好不到哪去。如果有两种虚伪的评测指标摆在厂商面前，一种能够促进销售，另外一种对销售没有什么好处，那么厂商会选择哪一种呢？结果很容易预测。不幸的是，厂商在MHz上的竞争将处理器引向了另外一条道路 ? 更大、更复杂的单线程系统。这与CMP的宗旨相去甚远，而且越来越远。
执行问题。如果要将传统的复杂核心变成成功的产品，我们中的许多人可能会低估其工程方面难以想象的难度。因此，似乎用退而求其次的方式才能得到成功的解决方案，将才智、动力和执行这些因素通过适当的组合变成真正的产品。
线程并非无处不在的。虽然服务器一级的工作负荷在很多年以前就可以实现多线程运行，但桌面工作负荷中却很少出现这种情况。因为桌面系统的数量巨大，而服务器CPU的开发和制造成本又极其高昂，桌面处理器的收益有很大一部分都被用于补贴服务器 CPU的研发工作。由于桌面系统缺乏多线程能力，CMP就不可能轻松地实现广泛的应用，其推广的急迫性也就不复存在。我将在本文的后面的部分对这一问题进行详细的探讨。
采用可怕的线程
业界采用CMP设计的步伐非常缓慢，这反映出人们对CMP机遇的担忧。业界担心，只有当有足够的线程时才能够充分发挥CMP的优势。这种担忧的根源主要是两方面的因素：并行编程的复杂性和普通应用的线程级加速潜力。
并行软件的复杂性很可能会降低程序员的生产效率，使程序员很难写出正确的、有效率的程序。计算机科学专业的学生对并行编程的了解是很有限的，而且也没有哪一种常用的语言与生俱来就可以支持并行计算技术。另外自动编译器并行技术的发展也相当缓慢，这些因此都使人们担心很多应用根本来不及充分发挥多线程芯片的优势。
当然，也有乐观的一面。小型多处理器的使用范围正在逐步扩大，这使得更多的程序员能够接触到并行处理硬件。而且市场上也出现了越来越多的工具，可以帮助程序员查找错误和性能问题（例如线程检查程序8和性能调试程序9）。另外，一些专家级的程序员能够编写与效率较高的线程代码，其中程序员也可以充分利用这些资源。快速锁定和线程高效内存分配库就是这类编程杰作中的典型例证，而且它们也被广泛地利用。从更大的规模上来说， Google的MapReduce10 等库使程序员可以更容易地编写高效的应用，并让这些应用使用数百个，甚至数千个线程在在大型数据集中完成采矿任务。的确有些算法是很难实现高效并行运行的，但多数需要CMP提供额外性能的问题级并不存在这种情况。除了一些特例外，基本上要想获得并行加速是比较容易实现的。这也就是为什么数据库应用的并行工作负荷在过去的十年中一直能够成功地运行。在Google公司里，我们通常可以对我们的CPU密集型工作负荷进行调整，使其可以在需要的时候使用更多的硬件线程。也就是说，只要硬件资源数量较大的服务器在经济上具备了足够的吸引力，我们就会毫不犹豫地选择多线程处理技术。
CMP面临的真正挑战并不是在服务器上，而是在桌面一级。许多常用的桌面应用都不具备并行处理能力，这部分是因为它们使用的数据集较小，另外也是因为直到最近几年多线程CPU才出现在桌面系统市场中。
随着越来越多的数据密集型工作负荷（如语音识别）成为桌面系统的常见应用，CMP系统对这部分市场的吸引力也会变得越来越大。
需要注意的是，对于那些并行处理能力较左的应用来说，CMP仍然是一种非常友好的目标平台。在CMP中，并发线程之间的通讯比传统的SMP系统要高得多，尤其是使用共享在片上缓存时，这种差距更是明显。因此，如果工作负荷需要在线程之间进行大量的通讯或同步，整体性能所受到的负面影响要小得多。如果用户需要对已经建立的代码库进行初期并行处理改造，那么在改造的过程中，CMP架构的这种特性将会使编程的负担大幅度减轻。
CMP逐步得到主流的接纳
对于Google提供的这类大规模服务来说，高性价比的分布式计算系统是必不可少的。在这些系统中，由于工作负荷的分布式特性，单线程的性能并不重要，重要的是整个系统的综合成本/性能比。芯片多处理技术非常适合满足此类要求。在运行原生并行工作负荷时，CMP可以比传统的乱序（wide-issue）单核心架构更好地利用片上集成的资源和内存系统，因此可以在芯片预算不变的前提下带来更高的性能。基本上，CMP比传统的CPU设计拥有更高的功率效率，因此可以帮助用户在未来的几年中有效控制能源消耗的成本。
然而，值得注意的是，单凭CMP并不能解决功率效率方面的挑战，但可以至少可以在未来的两至三代CPU上减轻这方面可能出现的问题。从长远趋势上来看，只有基本线路和架构上创新才是解决这类问题的根本道路。
计算机行业已经准备接受芯片多处理技术，并将其作为桌面和服务器市场中的主流解决方案，但似乎业界对CMP的接纳仍然有一些不情愿。只有当厂商必须将 CPU的温度保持在一个安全的热值包线内时，CMP并行技术才有可能成为必然的选择。这种方法虽然可以将单线程性能方面的损失减至最低程度，但它也很可能无法实现芯片多处理技术完整的成本效益潜力。一些厂商都将赌注押在了速度较慢的核心上，希望它们能够对高性能系统的经济性产生积极的影响，但事实上这种赌博的风险更大。
