2005年10月18日
第3卷，第7期

性能的代价

芯片多处理的经济案例

LUIZ ANDRÉ BARROSO，谷歌

在 20 世纪 90 年代后期，我们在 DEC 的研究小组是越来越多倡导 CMP（芯片多处理器）替代高度复杂的单线程 CPU 的团队之一。我们当时正在设计 Piranha 系统，¹ 这是一个 CMP 设计空间中的激进点，因为我们使用了非常简单的内核（类似于 80 年代后期的早期 RISC 设计）来提供更高水平的线程级并行性。我们的主要目标是在给定的硅预算下实现最佳的商业工作负载性能。

今天，在开发谷歌的计算基础设施时，我们的关注范围不仅仅局限于性能。衡量特定架构优点的标准是回答以下问题：您是否能够负担得起您需要的计算能力？谷歌的大多数服务都具有内在的高计算需求，这使我们对计算的总体成本有了深刻的理解，并不断寻找能够优化单位成本性能的硬件/软件设计。

本文探讨了大型互联网服务基础设施中的一些成本趋势，并强调了基于 CMP 的系统在提高整体计算平台成本效率方面的挑战和机遇。

理解系统成本

系统社区已经开发了一整套工具来衡量、建模、预测和优化性能。然而，社区对成本因素的认识和理解仍然不够深入。如果没有对成本进行彻底的考虑和理解，任何一种技术或产品的真正价值都仍然无法得到证实。

我们可以将大型计算集群的 TCO（总拥有成本）分解为四个主要组成部分：硬件价格、电力（经常性成本和初始数据中心投资）、经常性数据中心运营成本以及软件基础设施成本。

通常，商业部署的 TCO 的主要组成部分是软件。对 TPC-C 基准测试文件中使用的系统的价格细分进行粗略检查表明，仅操作系统和数据库引擎的每 CPU 成本就可能在 4,000 美元到 20,000 美元之间。² 一旦加上其他系统软件组件、应用程序和管理软件的许可费用，它们可能会使所有其他成本组成部分都相形见绌。对于使用中低端服务器的部署尤其如此，因为这些部署往往拥有大量不太昂贵的机器，但由于仍然普遍存在的每 CPU 或每服务器许可费政策，可能会产生巨大的软件成本。

谷歌选择内部生产自己的软件基础设施并与开源社区合作，通过大幅降低软件成本来改变成本分配（软件开发成本仍然存在，但会在大量的 CPU 部署中摊销）。因此，它需要特别关注剩余的成本组成部分。在这里，我将重点关注更直接受系统设计选择影响的成本组成部分：硬件和电力成本。

图 1 显示了谷歌服务器平台三个连续代的性能、每服务器价格性能和每瓦性能趋势。谷歌的硬件解决方案包括使用低端服务器。³ 此类系统基于大批量的 PC 级组件，因此在连续几代中以大致相同的成本提供不断提高的性能，从而导致每服务器价格性能曲线呈上升趋势。谷歌的容错软件设计方法使其能够基于这些相对不太可靠的构建块提供高可用性服务。

然而，即使在为提高电源效率做出重大努力之后，每瓦性能仍大致保持不变。换句话说，性能的每一次提升都伴随着平台整体功耗的成比例增加。这些趋势的结果是，与电力相关的成本在 TCO 中所占的比例越来越大。

这些趋势可能会对计算成本的计算方式产生重大影响。以下分析忽略了其他间接电力成本，而仅关注能源成本。如今，一台典型的低端 x86 服务器的成本约为 3,000 美元，平均功耗为 200 瓦（峰值功耗可能超过 300 瓦）。典型的电力输送效率低下和冷却开销很容易使能源预算翻倍。如果我们假设基本能源成本为每千瓦时 9 美分，服务器生命周期为四年，那么今天该系统的能源成本已经超过硬件成本的 40%。

情况还会变得更糟。如果未来几年每瓦性能保持不变，电力成本很容易超过硬件成本，甚至可能大幅超过。图 2 描绘了这种外推，假设了四种不同的年度性能和功耗增长率。对于最激进的情况（50% 的年增长率），到本十年末，电力成本将使服务器价格相形见绌（请注意，这并未考虑未来几年能源成本可能上涨的情况）。在这种极端情况下，机器的电力成本明显高于机器本身，人们可以设想出一些奇怪的商业模式，即电力公司会与您签订长期电力合同，并为您提供免费硬件。

计算机设备功耗可能失控的可能性可能会对计算的总体可负担性产生严重后果，更不用说地球的整体健康状况了。应该注意的是，尽管 CPU 仅占系统总功耗预算的一小部分，但在低端服务器平台上，这一比例很容易达到 50% 到 60%。

CMP 和计算效率

最终引入采用 CMP 技术的处理器是避免上述可怕未来的最佳（或许也是唯一）机会。正如本期开篇文章（Kunle Olukotun 和 Lance Hammond 的“微处理器的未来”）中所讨论的那样，如果线程级并行性可用，那么将晶体管和能源预算用于额外的内核比我们所知的任何其他技术都更有可能产生更高的性能。在这种线程丰富的环境中，预测和推测技术需要非常准确，才能证明它们所需的额外能量和空间是合理的，因为会有来自其他线程的非推测指令准备好执行。不幸的是，已知许多服务器级工作负载表现出较差的指令级并行性；⁴ 因此，它们与当今常见的激进的推测性乱序内核不太匹配。

谷歌的一些关键工作负载也表现出这种行为。例如，我们的索引服务应用程序在现代处理器上平均每两个 CPU 周期仅完成一条指令，严重地未充分利用可用的多个发射槽和功能单元。这是由于使用了对于片上缓存来说太大的数据结构，以及依赖于数据的控制流，这使得流水线暴露于较大的 DRAM 延迟。这种行为还会导致内存系统未被充分利用，因为通常在先前的内存访问结果可用之前，无法发出新的内存访问。控制流和内存访问流中都有足够的不确定性，使得推测技术相对无效。然而，相同的工作负载在传统多处理器、同步多线程系统和 CMP 上表现出出色的线程级加速。⁵

Piranha 的实现吸取了商业工作负载行为的教训：如果有足够的线程（硬件和软件），就不应该进行推测。八个 CPU 内核是对早期 RISC 设计的回溯：单发射、按序、非推测。第一款 Piranha 芯片有望以几乎一半的功耗超越当时最先进的 CPU 两倍以上。特别重要的是，这是在我们的团队完全忽略电源效率作为设计目标的情况下实现的。这很好地说明了 CMP 模型的固有电源效率优势。

最近的产品公告也提供了对 CMP 微架构电源效率潜力的见解。 AMD 和英特尔都在推出 CMP 设计，这些设计大致保持在其上一代单核产品的功耗范围内。例如，AMD 报告称，其双核 Opteron 275 型号在一系列基准测试中比其单核同等产品 (Opteron 248) 性能高出约 1.8 倍，⁶ 而功耗包络的增加不到 7%。即使我们悲观地假设整个平台的功耗也增加了相同的量，双核平台的电源效率（每瓦性能）仍然比单核平台高出近 70%。诚然，工艺技术的进步在实现这一目标中发挥了重要作用，但事实仍然是，在许多处理器代之后，我们首次看到了显着的电源效率提升。

步伐缓慢

在我们于 2000 年发表的第一篇 Piranha 论文中，我们将芯片多处理描述为微架构演进中不可避免的下一步。尽管这不再是一个有争议的观点，但令人惊讶的是，这种架构花费了如此长的时间才获得广泛接受。我尤其感到惊讶的是，更激进的 CMP 架构——那些（如 Piranha）以牺牲单线程性能为代价来换取额外线程级并行性的架构——现在才开始出现在商业产品中⁷，并且在相当长一段时间内不太可能广泛普及。

CMP 的商业化引入似乎遵循了一种更为谨慎的方法，随着每代工艺技术晶体管预算的增加，相当复杂的内核正在缓慢地添加到芯片上。如果 CMP 具有如此引人注目的潜力，为什么实现这种潜力需要如此长的时间？这主要有四个原因：

关键在于功耗包络，笨蛋。 事实证明，与我们在 Piranha 开发期间设想的不同，仅设计复杂性和性能不足以触发向 CMP 架构的转变；电力才是关键。为了避开昂贵的冷却技术，芯片开发商不得不将功耗密度控制在界限内，而使用传统技术越来越难以满足这些界限。

营销很重要。 兆赫兹是一个易于理解并传达给消费者的性能指标。尽管它是一个非常糟糕的应用程序性能指标，但对于大多数流行的基准测试来说也是如此。当在一种能够销售的虚假指标和一种不能销售的指标之间做出选择时，结果是可预测的。不幸的是，MHz 竞赛加强了向更大、更复杂的单线程系统发展的方向，并远离了 CMP。

执行力很重要。 我们许多人低估了将传统的复杂内核变成非常成功的产品所付出的巨大工程努力。似乎次优的架构可以通过人才、干劲和执行力的正确结合变成成功的解决方案。

线程尚未普及。 尽管服务器级工作负载多年来一直是多线程的，但桌面工作负载的情况并非如此。由于桌面销量仍然在很大程度上补贴了服务器 CPU 开发和制造的巨额成本，因此桌面中缺少线程使得 CMP 的普遍吸引力降低。我将在本文后面详细阐述这个问题。

畏惧线程化

业界在采用 CMP 设计方面的迟缓很大程度上反映了一种担忧，即 CMP 的机会取决于是否有足够的线程来利用该机会。这种担忧似乎主要基于两个因素：并行编程的复杂性和常见应用程序的线程级加速潜力。

并行软件的复杂性会降低程序员的生产力，因为它使编写正确且高效的程序变得更加困难。计算机科学专业的学生接触并行编程的机会有限，缺乏对并行性提供原生支持的流行语言，以及自动编译器并行化技术的进展缓慢，所有这些都加剧了人们的担忧，即许多应用程序将无法准备好利用多线程芯片。

不过，我们有理由保持乐观。小型多处理器日益普及，这使得更多程序员接触到并行硬件。越来越多的工具可用于发现正确性和性能问题（例如，线程检查器⁸ 和性能调试器⁹）。此外，少数专家程序员可以编写高效的线程代码，而这些代码反过来又被许多其他人利用。快速锁定和线程高效的内存分配库是高度利用编程工作的良好示例。在更大的范围内，诸如谷歌的 MapReduce¹⁰ 之类的库可以使程序员更容易编写高效的应用程序，这些应用程序可以使用数百或数千个线程来挖掘海量数据集。

虽然有些算法确实难以有效地并行化，但大多数需要 CMP 额外性能的问题类别并非如此。这里的一般原则是，除了少数例外，数据越多，就越容易获得并行加速。这也是数据库应用程序在十多年来一直成功作为并行工作负载运行的原因之一。在谷歌，我们通常能够调整我们的 CPU 密集型工作负载，以便在需要时扩展到越来越多的硬件线程——也就是说，只要具有更多硬件上下文的服务器在经济上变得有吸引力。

CMP 的真正挑战不在于服务器级别，而在于桌面级别。许多流行的桌面应用程序尚未并行化，部分原因是它们处理的数据集适中，部分原因是多线程 CPU 最近才被引入该市场领域。随着更多数据密集型工作负载（例如语音识别）在桌面端变得普遍，CMP 系统对于该领域将变得越来越有吸引力。

重要的是要注意，CMP 是不擅长并行化的应用程序的友好目标平台。 CMP 中并发线程之间的通信速度可能比传统 SMP 系统快一个数量级，尤其是在使用共享片上缓存时。因此，需要线程之间进行大量通信或同步的工作负载将付出较小的性能代价。 CMP 架构的这一特性应有助于减轻初始并行化已建立代码库所涉及的编程负担。

CMP 走向主流接受

对于像谷歌提供的那些大型服务来说，高成本效率的分布式计算系统至关重要。对于这些系统，考虑到工作负载的分布式性质，单线程性能远不如整个系统的总成本/性能比重要。芯片多处理非常适合此类要求。在运行这些固有的并行工作负载时，与传统的宽发射单核架构相比，CMP 可以更好地利用片上资源和内存系统，从而在给定的硅预算下实现更高的性能。 CMP 在根本上也比传统的 CPU 设计更节能，因此将有助于在未来几年内控制电力成本。然而，请注意，CMP 无法单独解决电源效率挑战，而只能在未来两到三代 CPU 中缓解这一挑战。仍然需要根本性的电路和架构创新来应对更长期的趋势。

计算行业已准备好接受芯片多处理作为桌面和服务器市场的主流解决方案，但它似乎有些不情愿地这样做。仅当绝对必要保持在安全的散热包络内时，才引入 CMP 并行性。这种方法最大限度地减少了单线程性能的任何重大损失，但不太可能充分发挥芯片多处理的全部成本效率潜力。在较慢的内核上进行风险更高的押注可能会对高性能系统的可负担性产生更大的积极影响。

参考文献

1. Barroso, L. A., Gharachorloo, K., McNamara, R., Nowatzyk, A., Qadeer, S., Sano, B., Smith, S., Stets, R., and Verghese, B. 2000. Piranha: a scalable architecture based on single-chip multiprocessing. Proceedings of the 27th International Symposium on Computer Architecture (June), Vancouver, BC.

2. Transaction Processing Performance Council. Executive summary reports for TPC-C benchmark filings; http://www.tpc.org.

3. Hoelzle, U., Dean, J., and Barroso, L. A. 2003. Web search for a planet: the architecture of the Google cluster. IEEE Micro Magazine (April).

4. Ranganathan, P., Gharachorloo, K., Adve, S., and Barroso, L.A. 1998. Performance of database workloads on shared memory systems with out-of-order processors. Proceedings of the Eighth International Conference on Architecture Support for Programming Languages and Operating Systems (ASPLOS VIII), San Jose, CA.

5. 参见参考文献 3。

6. AMD competitive server benchmarks; http://www.amd.com/usen/Processors/ProductInformation/0,,30_118_8796_8800~97051,00.html.

7. Kongetira, P., Aingaran, K., and Olukotun, K. 2005. Niagara: a 32-way multithreaded SPARC processor. IEEE Micro Magazine (March/April); http://www.computer.org/micro.

8. Intel Corporation. Intel thread checker; http://developer.intel.com/software/products/threading/tcwin.

9. Seward, J. Valgrind; http://valgrind.kde.org/.

10. Dean, J., and Ghemawat, S. 2004. MapReduce: simplified data processing on large clusters. Proceedings of OSDI, San Francisco, CA.

致谢

作者感谢 Wolf-Dietrich Weber 和 Christopher Lyle Johnson 对手稿的仔细审阅。

LUIZ ANDRÉ BARROSO 是谷歌的首席工程师，领导平台工程团队。他曾从事谷歌系统基础设施的多个方面的工作，包括负载均衡、故障检测和恢复、通信库、性能优化和计算平台设计。在加入谷歌之前，他曾在 Compaq 和 DEC 的研究部门工作，在那里他研究了用于商业工作负载的处理器和内存系统架构，并共同设计了 Piranha 系统。 Barroso 拥有南加州大学计算机工程博士学位，以及巴西 PUC-Rio 电气工程学士和硕士学位。

最初发表于 Queue 第 3 卷，第 7 期—
在数字图书馆中评论本文

更多相关文章

Michael Mattioli - 客户端计算硬件中的 FPGA
FPGA（现场可编程门阵列）具有非凡的通用性。它们广泛应用于各种应用和行业，在这些应用和行业中，使用 ASIC（专用集成电路）在经济上不太可行。尽管设计师在将 FPGA 集成到设备中时面临面积、成本和功耗方面的挑战，但它们提供了显着的安全性和性能优势。其中许多优势可以在客户端计算硬件（如笔记本电脑、平板电脑和智能手机）中实现。

Christoph Lameter - NUMA（非一致性内存访问）：概述
NUMA（非一致性内存访问）是一种现象，即处理器地址空间中各个点的内存具有不同的性能特征。在当前的处理器速度下，从处理器到内存的信号路径长度起着重要作用。信号路径长度的增加不仅增加了内存的延迟，而且如果信号路径由多个处理器共享，则很快就会成为吞吐量瓶颈。内存的性能差异首先在大型系统中显现出来，在这些系统中，数据路径跨越主板或机箱。这些系统需要修改后的具有 NUMA 支持的操作系统内核，这些内核明确了解系统的内存拓扑属性（例如内存区域所在的机箱），以避免过长的信号路径长度。

Bill Hsu, Marc Sosnick-Pérez - 实时 GPU 音频
今天的 CPU 能够为许多流行的应用程序支持实时音频，但一些计算密集型音频应用程序需要硬件加速。本文着眼于一些实时声音合成应用程序，并分享作者在 GPU（图形处理单元）上实现它们的经验。

David Bacon, Rodric Rabbah, Sunil Shukla - 面向大众的 FPGA 编程
当我们研究硬件如何影响计算性能时，我们在一端有 GPP（通用处理器），另一端有 ASIC（专用集成电路）。处理器具有高度可编程性，但在功耗和性能方面通常效率低下。 ASIC 实现专用和固定功能，并提供最佳的功耗和性能特性，但任何功能更改都需要完全（且极其昂贵）地重新制作电路。