面向大众的多核 CPU

Mache Creeger，新兴技术协会

多核是英特尔、AMD、Sun 等公司最新一代 CPU 中的热门话题。随着时钟速度的提升变得越来越困难，供应商已转向多核 CPU，将其作为获得额外性能的最佳方式。客户对以相同的实际投入通过并行处理器获得更高性能的前景感到兴奋。

对于少数流行的基于服务器的企业应用程序来说，这可能是真的，但对于桌面应用程序，我不会指望这个承诺很快就能实现。对桌面多核 CPU 的期望是让我们的所有桌面应用程序都充分利用芯片上的所有处理器核心。随着越来越多的处理器可供使用，每个应用程序的性能都会优雅地提升。就像过去时钟速度和应用程序带宽的提升一样，增加处理器核心的数量应该会产生类似的性能增强。这对流行的企业应用程序有效，为什么对桌面应用程序无效呢？听起来合理，对吧？别指望它。

当然，主要的的企业应用程序，如 Oracle、WebLogic、DB2 和 Apache，都旨在充分利用多处理器，并被架构为 MT（多线程）。对于大型 SMP（对称多处理）服务器来说，它们必须如此，因为这些服务器是它们市场的核心。

尽管使用并发 CPU 来提高整体软件性能的概念已经存在至少 35 年了，但商业市场上与开发工具相关的成果却非常少。因此，绝大多数应用程序都是单线程的。虽然多核 CPU 允许您在多个处理器之间共享混合应用程序，但单个应用程序的性能仍将受限于单个处理器的速度。无论您有一个还是 100 个处理器，应用程序性能都将保持不变，因为每个应用程序在任何给定时间只能在一个处理器上运行。

除了可能的 Java 之外，没有广泛使用的带有 MT 扩展的商业开发语言。实际上，直到现在还没有太大的需求。商业 SMP 系统的广泛普及实际上直到 1990 年代初期才到来，即使在那时，多线程应用程序的普及也很缓慢。

当我在 Sun 公司时，公司重写了 SunOS 以利用其新的多线程架构。这是一个漫长而痛苦的过程。最初，子系统被重写，两端都带有锁，以确保它们作为一个大型单线程（MT 安全）运行，然后再次重写以实现完全 MT 优化（MT 热），以获得最大的并发性。一切都是手工设计的，没有任何工具来管理复杂性。

大约在同一时间，Sun 公司实现了一组用户 MT 库，应用程序可以使用这些库。随着更大的 SMP 服务器开始出现在 Sun 的路线图上，主要的的企业应用程序供应商意识到他们也必须投资将其软件转换为 MT。这段经历同样痛苦，并且类似于 SunOS MT 的重写。Sun 公司认识到需要使这些应用程序 MT 热运行，以便销售其新的 SMP 服务器，因此利用其经验，派遣工程师到这些公司帮助他们进行迁移。

今天的情况正在迅速重演 10 年前发生的事情。需要更多 CPU 带宽的应用程序供应商不能再指望通过提高时钟速度来获得更好的性能和功能。大多数大型客户端应用程序都是用 C 或 C++ 编写的，并且在历史上被设计为单线程的。使应用程序 MT 热仍然是一个劳动密集型的重新交付过程。虽然一些供应商，尤其是多媒体领域的供应商，已经对其应用程序进行了一些 MT 增强，但他们只是开始摘取低垂的果实。有了多核 CPU，广泛的桌面性能和功能改进仍然遥遥无期。

在过去的十年左右，随着 MT 架构的演进，开发工具供应商一直在做什么？计算机行业中似乎没有人预见到这种情况的到来。我们对未来有什么期望？鉴于行业目前的状况，基于多核 CPU 的桌面系统的推出将会停滞不前，因为客户发现他们的大多数应用程序在双核或四核系统上的运行速度并不比在单核系统上快。为了销售更多的机器/CPU，硬件供应商将不得不像 Sun 公司那样做，并“鼓励”应用程序供应商重新设计其应用程序以使其成为 MT 热。那些一直能够依赖持续 CPU 时钟速度提升的桌面应用程序供应商现在将不得不投资对其软件进行漫长而痛苦的重写，以获得性能和功能的下一个飞跃。所有这些可能需要数年时间。此外，更敏捷的公司现在将有机会更快地进行 MT 热投资，从而有可能从那些转型太慢的现有供应商那里抢走客户。

令人沮丧的是，所有这一切本来是可以避免的。MT 至少在十年前就已初见端倪。由于科技公司在其规划中采取了短视的季度视角，他们错过了多核 CPU 及其对桌面影响的更大趋势。因此，当这些新的 CPU 进入市场时，MT 开发工具尚未到位。除了 Java 的最低限度的 MT 支持之外，情况看起来与 10 多年前大型企业应用程序开发人员不得不面对的情况非常相似。

可悲的是，我看到以下情景正在上演。应用程序开发人员需要花费数年的痛苦时间来重写他们的代码以使其成为 MT 热。一旦建立了转换方法，IDE 工具供应商将开始推出自动化扩展，以帮助管理 MT 开发的复杂性。这两个过程很容易需要三到五年时间。一旦 MT 增强的 IDE 产品变得成熟，语言扩展将会随之而来。具有完全集成的 MT 控制结构的商业认可的开发语言应该会在五到七年内得到广泛使用。在此期间，不要指望随着每个新 CPU 系列的发布，桌面应用程序的性能会立即提升。对于多核系统，在桌面上拥有 CPU 带宽和能够使用它是两件截然不同的事情。

MACHE CREEGER ([email protected]) 是拥有 30 年技术行业经验的资深人士。他是新兴技术协会的负责人，为技术公司提供市场营销和业务发展咨询。

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

更多相关文章

David Collier-Brown - 你对应用程序性能一窍不通
当您遇到性能或容量规划问题时，无需进行全面的基准测试。一个简单的测量将提供您系统的瓶颈点：这个示例程序在每个 CPU 每秒处理八个请求后，速度会明显变慢。这通常足以告诉您最重要的事情：您是否会失败。

Peter Ward, Paul Wankadia, Kavita Guliani - 重塑 Google 的后端子集化
后端子集化对于降低成本非常有用，甚至对于在系统限制内运行可能是必要的。十多年来，Google 使用确定性子集化作为其默认的后端子集化算法，但尽管此算法平衡了每个后端任务的连接数，但确定性子集化具有较高的连接流失率。我们在 Google 的目标是设计一种具有降低的连接流失率的算法，该算法可以取代确定性子集化成为默认的后端子集化算法。

Noor Mubeen - 工作负载频率缩放定律 - 推导与验证
本文介绍了与每个 DVFS 子系统级别的工作负载利用率缩放相关的公式。建立了频率、利用率和比例因子（其本身随频率变化）之间的关系。这些方程的验证被证明是棘手的，因为工作负载固有的利用率也似乎以未指定的方式在治理样本的粒度上变化。因此，应用了一种称为直方图脊迹的新方法。当将 DVFS 视为构建块时，量化缩放影响至关重要。典型应用包括 DVFS 调速器和/或其他影响系统利用率、功耗和性能的层。

Theo Schlossnagle - DevOps 世界中的监控
监控似乎非常令人难以承受。最重要的事情是记住，完美永远不应成为更好的敌人。 DevOps 使组织内部能够进行高度迭代的改进。如果您没有监控，那就获取一些；获取任何东西。有总比没有好，如果您已经拥抱了 DevOps，那么您已经同意随着时间的推移使其变得更好。