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

极限软件扩展

芯片多处理器为应用程序开发人员、操作系统设计人员和部署专家引入了新的扩展维度。

Richard McDougall，Sun Microsystems

SMP（对称多处理）的出现为计算机系统增加了新的可扩展性。SMP 系统不是从逐渐加快的微处理器中获得额外的性能，而是利用多个处理器来获得系统总性能的大幅提升。软件中的并行性允许在系统上同时执行多个作业，从而相应地提高系统吞吐量。如果有足够的软件并行性，这些系统已被证明可以扩展到数百个处理器。

最近，类似的现象正在芯片级别发生。制造商不再追求通过提高单个处理器性能来获得递减的回报，而是生产在单个芯片上具有多个处理器内核的芯片。（参见本期 Kunle Olukotun 和 Lance Hammond 的文章“微处理器的未来”）。例如，AMD Opteron1 处理器现在每个芯片使用两个完整的处理器内核，提供的性能几乎是单核芯片的两倍。图 1 显示的 Sun Niagara2 处理器每个芯片使用八个内核，其中每个内核进一步复用四个硬件线程。

这些新的 CMP（芯片多处理器）正在将曾经是大型多处理器系统的东西带到芯片级别。低端四芯片双核 Opteron 机器在软件看来是一个八处理器系统，而在 Sun Niagara 处理器（每个内核有八个内核和四个线程）的情况下，单个芯片在软件看来是一个 32 处理器系统。因此，系统和应用程序软件同时利用多个处理器或线程的能力变得比以往任何时候都更加重要。随着 CMP 硬件的发展，软件也需要相应地扩展，以充分利用芯片的并行性。

因此，将这种程度的并行性降低到芯片级别代表了我们思考扩展方式的重大变革。由于 CMP 系统的成本与近期低端单处理器系统的成本相近，因此即使是最便宜的桌面电脑和服务器也必然是高度线程化的。用于在大型企业级 SMP 系统上扩展应用程序和系统软件的技术现在将经常被利用，以便即使对于单芯片系统也能提供可扩展性。我们需要考虑扩展程度的变化对我们构建应用程序的方式、我们选择的操作系统以及我们用于部署应用程序的技术（即使在低端）的影响。

CMP：仅仅是具有成本效益的 SMP 吗？

对 CMP 系统的一种简单看法是，它在软件看来是一个 SMP 系统，其处理器数量等于芯片中的线程数，每个线程的处理能力略有降低。由于每个硬件线程都共享单个处理器内核的资源，因此每个线程都具有内核整体性能的一部分。因此，一个具有 32 个硬件线程的八核芯片以 1 GHz 运行，可以粗略地近似为一个具有 32 个 250 MHz 处理器的 SMP 系统。对软件的影响通常是在单线程延迟方面的细微权衡，以换取吞吐量的显着增加。对于具有许多并发请求的面向吞吐量的工作负载（例如 Web 服务器），响应时间的边际增加几乎可以忽略不计，但系统吞吐量的增加比相同时钟速度的非 CMP 处理器高出一个数量级。

然而，CMP 系统和 SMP 系统之间存在更微妙的差异。如果 CMP 处理器内的线程或内核共享重要资源，则某些线程可能会影响其他线程的性能。例如，当多个线程共享单个内核并因此共享一级内存缓存时，给定线程的性能可能会因同一内核的其他线程对缓存中的第一个线程的数据执行的操作而异。然而，在另一个类似的情况下，如果其他线程建设性地共享缓存，则线程实际上可能会受益，因为有用的数据可能会被第一个线程以外的线程带入缓存。稍后当我们探讨一些潜在的操作系统优化时，将更详细地介绍这一点。

扩展软件

理想情况下，系统软件的性能应与系统中的处理器数量成比例地扩展。然而，有一些因素限制了加速。

阿姆达尔定律³ 将可扩展性定义为并行算法的加速，实际上受到必须顺序执行的操作数量（即其串行部分）的限制，如图 2 所示。如果并行程序中有 10% 的串行代码，则使用四个处理器（线性速度的 75%）可以达到的最大加速为三，当处理器数量增加到八个时（仅为线性的 59%）则降低到仅为 4.75。阿姆达尔定律告诉我们，随着处理器数量的增加，串行部分对加速施加了严重的约束。

此外，软件通常会因通信和将工作分配给多个处理器而产生开销。这导致性能曲线出现峰值，然后开始下降（参见图 3）。

由于大多数操作系统和应用程序都包含一定数量的顺序代码，因此阿姆达尔定律的一个可能的结论是，构建具有大量处理器的系统是不划算的，因为永远不会产生足够的加速。然而，在过去十年中，重点一直放在减少硬件架构、操作系统、中间件和应用程序软件中的串行部分。如今，在 SMP 系统上扩展系统软件和应用程序到 100 个处理器的数量级是可能的。图 4 显示了一系列扩展基准测试的结果，这些基准测试是在大型 SMP 配置上使用数据库工作负载执行的。这些应用程序基准测试是在单系统映像上通过测量吞吐量（随着处理器数量的增加）来执行的。

机器内扩展还是机器间扩展？

这些大型 SMP 机器的软件可扩展性在历史上是通过严格关注单个操作系统内应用程序的一个大型实例中的机器内可扩展性来实现的。SAP 等单层企业应用程序就是一个很好的例子。SAP 的原始版本使用了单个且大型的单体应用程序服务器。应用程序实例从用户的许多并发请求中获得其并行性。只要用户之间没有主要的序列化点，应用程序自然会扩展。扩展这些应用程序的重点是消除应用程序内的这些序列化点。

最近，由于低端系统的经济性，重点已转向利用机器间扩展，使用低成本的商品化单处理器到双处理器服务器。通过在单独的单处理器到双处理器系统上并行运行多个实例，可以使某些应用程序进行扩展，而无需大型、昂贵的 SMP 系统，从而获得良好的总体吞吐量。可以通过将所有共享状态移动到共享后端服务（如数据库）来设计应用程序以这种方式进行扩展。许多单处理器到双处理器系统配置为中间层应用程序服务器，与机器内扩展的数据库系统通信。重点转向单处理器到双处理器硬件已消除了将机器内可扩展性设计到软件中的大部分压力。

CMP 的引人注目的特性（低功耗、极高密度和高吞吐量）与此空间非常匹配，这要求重新关注机器内可扩展性。

CMP 对应用程序开发人员的影响

对于应用程序开发人员来说，最重要的影响是扩展的要求。最低扩展要求已从 1-4 个处理器提高到今天的 32 个，并且在不久的将来可能会再次增加。

构建可扩展的应用程序

工程化可扩展代码具有挑战性，但性能提升巨大。图 4 中 Oracle 和 DB2 的扩展曲线中的数据展示了回报，这来自于大量的性能调整和扩展优化。根据阿姆达尔定律，扩展软件需要最大限度地减少工作负载的串行部分。在许多商业系统中，自然的并行性来自于系统的许多并发用户。

简单的一阶扩展瓶颈（那些具有较大串行部分的瓶颈）通常来自对共享资源的争用，例如

网络或互连。 系统各部分之间互连的带宽限制——例如，Web 服务器上的入口网络、SQL 流量的 1 层和 2 层网络或 SAN（存储区域网络）。
CPU/内存。 由于资源匮乏而导致 CPU 排队或等待页面错误。
I/O 吞吐量。 磁盘 I/O 操作或带宽的容量不足。

更有趣的问题源于固有的应用程序设计。这些问题源于应用程序或操作环境中的串行操作。如果没有好的观察工具，它们通常更难识别，因为它们不会表现为易于检测的过载资源（例如 CPU 不够用），而是经常在负载增加时表现出越来越多的空闲资源。

这是一个常见的例子。我们最近被要求帮助解决一个大型在线电子商务系统的扩展问题。该应用程序由数千名用户通过 Web 应用程序执行支付交易组成。随着负载的增加，延迟变得不可接受。该应用程序在一个大型 SMP 系统和数据库上运行，这两者都以良好的扩展性而闻名。系统中没有明确的指标表明问题出在哪里。随着负载的增加，系统 CPU 资源变得更加空闲。结果证明，所有更新的中心是一个单表，表的锁定策略成为工作负载的重要串行部分。用户交易只是在等待表更新。解决方案是分解表，以便可以进行并发插入，从而减少串行部分并提高可扩展性。

对于 CMP，我们需要关注什么可能会限制一个应用程序实例内的扩展，因为我们现在需要扩展到数十个线程，并在不久的将来增加到 100 个线程的数量级。

编写可扩展的底层代码

许多中间件应用程序（例如数据库、应用程序服务器或事务系统）需要特别注意扩展。以下是一些常用技术，可以作为一般指南。

可扩展的算法。 随着问题集大小的增加，许多算法的效率会降低。例如，使用线性列表搜索对象的算法将随着列表大小的增加而增加所需的 CPU 量，可能以超线性速率增加。选择针对常见情况优化的良好算法至关重要。

锁定。 锁定策略对可扩展性有重大影响。随着并发性的增加，尝试锁定对象或区域的线程数会增加，从而导致锁定变得“更热”时争用加剧。在现代系统中，最佳方法是尽可能使用细粒度锁定（每个对象一个锁）。还有几种方法可以在牺牲一些内存浪费或增加写入端成本的情况下使代码的读取器端无锁。

缓存行共享。 多处理器和 CMP 系统使用硬件一致性算法来保持不同流水线之间的数据一致性。这可能会对扩展产生重大影响。例如，如果一个处理器更新其缓存中的内存对象，而该对象也从另一个处理器访问，则可能会导致延迟惩罚。由于缓存一致性硬件协议确保仅存在一个版本的数据，因此缓存位置将被无效。在 CMP 系统中，多个线程通常访问单个一级缓存；因此，将将在单个内核中访问的数据并置可能是合适的。

工作线程池。 并发性的一个好方法是使用工作线程池；通用、多线程引擎可用于处理聚合的工作事件集。使用此模型，应用程序将离散的工作单元交给引擎，并让引擎并行处理它们。工作线程池提供了一种灵活的机制，可以在多个处理器或硬件线程之间平衡工作事件。操作系统可以自动调整应用程序的并发性以满足底层硬件体系结构的拓扑。

内存分配器。 内存分配器对扩展提出了重大问题。几乎每个代码都需要分配和释放数据结构，并且通常通过中央系统提供的内存分配器来完成。不幸的是，很少有内存分配器可以很好地扩展。少数可以扩展的包括开源 Hoard、Solaris 10 的 libumem slab 分配器和 MicroQuill 的 SmartHeap。值得关注可扩展性的多个维度：不同的分配器在分配/释放请求的性质方面具有不同的属性。

尽早且经常地进行可扩展性实验

时间表明，从应用程序中消除扩展问题的最有效方法是进行扩展研究。鉴于可以进行优化的无限空间，遵循方法来优先考虑最重要的问题非常重要。

建模技术可用于数学方式预测复杂系统中的响应时间和潜在的扩展瓶颈。它们通常用于预测硬件的性能，以帮助进行设计权衡分析。然而，建模软件需要深入了解软件算法、代码路径和系统服务延迟。构建模型和验证所有假设所需的时间通常与运行扩展测试相悖。

一组精心设计的扩展实验是理解应用程序性能特征的关键，并且通过适当的观察工具，很容易查明关键问题。可扩展性预测和分析应尽早地在开发周期中完成。对现有架构进行可扩展性改进通常要困难得多。将可扩展性视为应用程序架构和设计的一部分。

可扩展性实验中要包含的关键项目是

吞吐量与线程/处理器数量的关系。随着应用的资源量增加，吞吐量是否接近线性扩展？
吞吐量与每个事务消耗的资源（即 CPU、网络 I/O 和磁盘 I/O）的关系。每个工作单元消耗的资源量是否随着规模的增加而增加？
延迟与吞吐量的关系。事务的延迟是否随着系统吞吐量的增加而增加？如果事务响应时间太长，则提供线性吞吐量可扩展性的系统在现实世界中可能没有用。
统计信息。以指令数和周期数衡量代码路径长度。

观察工具是实现可扩展软件的主要手段

有效的工具是提高应用程序可扩展性的最重要因素。能够快速识别扩展问题的根本原因至关重要。寻找扩展问题的目的是轻松查明最主要的序列化来源。

这些工具应有助于识别导致序列化的问题类型——两个经典案例是负载增加导致资源需求升级而导致的饥饿，以及负载增加导致空闲时间增加。理想情况下，这些工具应有助于识别扩展问题的来源，而不仅仅是指向争用对象。这有助于不仅识别争用点是什么，而且可能还有一些过度利用资源的不良代码。通常，一旦确定了来源，许多明显的优化就会变得显而易见。

考虑可以使用以下功能的工具

定位关键的等待时间来源。什么是争用的资源，哪个资源导致资源利用率，以及争用对整体性能有多大影响？
识别热同步锁。有多少挂钟时间和 CPU 时间在锁定对象中被序列化，以及哪个代码负责？
识别不可扩展的算法。哪些函数或类随着应用程序规模的增加而变得更昂贵？
明确问题所在。这可以在您可以影响的应用程序代码中完成，或者通过指向供应商提供的中间件或操作系统中的争用点来完成。即使争用点可能位于供应商代码中，也可能是由于调用该代码的方式造成的，而这可以通过优化更高级别的代码来影响。

CMT 和软件许可

硬件体系结构的扩展特性的另一个影响是软件许可。应用程序开发人员通常使用系统中的处理器数量来确定软件的价格。处理器数量一直是软件许可的便捷衡量标准，这主要是因为硬件平台的成本与处理器数量之间存在密切的相关性。通过使用按处理器数量索引的许可费，软件供应商可以收取大致成比例的软件费用。

然而，这是基于不再成立的旧假设。首先，CMT 平台上的操作系统为芯片中的每个线程报告一个虚拟处理器，从而导致低端系统的软件许可非常昂贵。软件供应商一直在争先恐后地调整最新的双核 CMT 系统，有些选择每个内核收取一次许可费，另一些则每个物理芯片收取一次许可费。按内核许可不公平地增加了每美元单位硬件的软件许可。

在短期内，操作系统供应商正在提供增强功能以报告系统中内核和物理处理器的数量，但迫切需要更合适（和公平）的解决方案。很可能将寻求使用标准基准测试的基于吞吐量的许可费。这将允许根据平台的实际处理能力收取许可费。当使用更高级的虚拟化方案（将处理器划分为子处理器部分）时（例如基于优先级的资源分区），这种方案将允许软件许可进行扩展。随着实用计算和服务器整合变得越来越流行，这些方案变得越来越普遍。操作系统供应商的机会是选择一个可以衡量和报告的统一指标，该指标基于应用程序的实际使用情况。

CMP 对操作系统的影响

操作系统面临的挑战是双重的：为它托管的应用程序提供可扩展的系统服务，并提供可扩展的编程环境，以方便并行程序的轻松开发。

操作系统的 CMP 增强功能

支持 SMP 的操作系统内核在 CMP 硬件上运行良好。由于芯片中的每个内核或硬件线程都有一整套寄存器，因此它们在软件看来是独立的 CPU。未更改的操作系统将简单地为芯片中的每个硬件线程实现一个逻辑处理器。软件线程将像在 SMP 系统中一样，根据操作系统内核的调度策略（见图 5）以相同的权重调度到每个硬件线程上。

针对 CMT 处理器进行优化的基本更改将包括消除任何忙等待循环。例如，空闲循环通常实现为忙旋转，该忙旋转检查运行队列以查找更多要完成的工作。当多个硬件线程共享单个内核时，在一个线程上运行的空闲循环会对共享内核流水线的其他线程产生不利影响。在本例中，利用硬件在没有工作要做时暂停线程的能力将更有效。

可能会进一步追求操作系统增强功能，以针对 CMP 的细微差异进行优化。例如，通过了解处理器体系结构以及有关软件行为的一些信息，调度程序可能能够优化将软件线程放置到特定的硬件线程上。在具有多个硬件线程共享内核、一级缓存和 TLB（转换后备缓冲区）的 CMP 体系结构的情况下，如果具有相似内存访问模式（建设性）的软件线程被并置在同一内核上，而具有破坏性模式的线程被分隔到不同的内核上，则可能会有好处。

操作系统扩展

操作系统服务扩展的挑战在历史上一直是服务实例之间的共享状态。例如，考虑一个全局进程表，任何想要启动新程序的程序都需要访问和更新该表。在多处理器系统中，必须使用同步技术来缓解当两个或多个线程尝试同时更新进程表时出现的竞争条件。

常用技术需要在访问这些结构的代码或数据结构本身周围进行序列化。早期将 Unix 移植到 SMP 硬件的尝试是粗糙的——它们通常是对现有操作系统代码的改造，具有简单、粗粒度的序列化。例如，第一个 SMP Unix 系统使用了略微修改的实现，操作系统内核周围有一个全局锁，用于序列化对其数据结构的所有请求。SunOS (1.x)、Linux (2.2) 和 FreeBSD (4.x) 内核的早期版本使用了这种方法。尽管易于实现，但这种方法仅对很少使用操作系统服务的应用程序有帮助。完全计算密集型的应用程序显示出良好的可扩展性，但那些使用大量操作系统服务的应用程序发现序列化产生的可扩展性几乎为零或根本没有超过一个处理器。

相比之下，成功的操作系统扩展是通过最大限度地减少争用，将序列化限制为数据结构的细粒度部分来实现的。通过这种方式，操作系统可以在多个处理器上同时在同一区域内执行代码，仅在访问共享数据结构时短暂地进行序列化。然而，这种方法确实需要对操作系统进行重大的架构更改，在某些情况下，需要从头开始重新设计，重点是可扩展性。

一个设计良好的操作系统允许通过其操作系统服务实现高水平的并发性。特别是，通过库、内存分配器和其他系统服务调用系统服务的应用程序必须能够并行执行，即使它们访问共享设施也是如此。例如，多个程序应该能够并发地分配内存而无需序列化。对可扩展性至关重要的其他领域包括对共享硬件（例如 I/O）和网络子系统的并行访问。

FreeBSD 中的扩展增强功能

FreeBSD 从 5.x 内核开始，已经看到了大量的扩展工作⁴。架构更改包括新的内核内存分配器、同步例程、向 ithreads 的迁移以及从进程调度、虚拟内存、虚拟文件系统、UFS（Unix 文件系统）、网络堆栈和几种常见的进程间通信形式中删除全局内核锁。FreeBSD 中的扩展工作已成功地改进了扩展（估计表明达到了 12 个处理器的数量级）。

Linux 中的扩展增强功能

Linux 2.2 内核通过分解全局内核锁大大提高了扩展性。据说可以扩展到两到四个处理器的数量级。Linux 2.4 通过在调度程序和 I/O 子系统中引入更细粒度的锁定，将扩展性提高到八到十六个处理器。这改进了许多项目的扩展性，包括中断和 I/O。Linux 内核后来的工作重点是扩展调度程序以适应更多数量的进程，并通过网络子系统提高并发性。

Solaris 中的扩展增强功能

Solaris 操作系统围绕并发性概念构建，序列化被限制在数据结构非常小且关键的部分。该操作系统围绕执行上下文是单个软件线程的概念进行设计，这些线程在可能的情况下被调度和并行执行。

用 Slab⁵ 和 Vmem⁶ 分配器替换原始 Unix 内存分配器带来了显着的可扩展性提升。这些分配器在对象集大小增长时提供一致的及时分配，并且它们特别注意通过提供每个处理器的内存池来避免锁定，这些内存池允许在无需访问全局结构的情况下进行分配和释放。

可扩展的 I/O 是通过允许请求线程即使在同一设备驱动程序中也能并发执行来实现的，并且进一步通过将来自硬件设备的中断作为单独的线程进行处理，从而允许中断处理的扩展⁷。

在某些情况下，需要对数据结构进行高水平的并发访问。例如，I/O 设备的性能统计信息需要来自可能数千个并发操作的更新。为了缓解围绕这些类型结构的争用，统计信息按每个处理器保存，然后在需要时进行聚合。这允许对更新进行并发访问，仅在读取统计信息时才需要序列化。

Solaris 网络代码经过重新架构，通过引入每个连接的垂直边界来消除大部分全局数据结构⁸。这允许 TCP/IP 实现以近乎无锁的模式在单个连接内运行，仅在发生路由更改等全局事件时才需要锁定。

集成的观察工具是优化扩展问题的关键。用于观察具有实时工作负载的系统上的锁定争用源的工具对于在重要领域进行改进至关重要。最近，Dtrace 可能是性能优化方面更具革命性的方法之一，它允许对 C 和 Java 代码进行动态检测⁹。它可以快速查明从应用程序堆栈顶部到操作系统的争用源。

这些类型的技术允许 Solaris 内核扩展到数千个线程、高达每秒 100 万次 I/O 以及数百个物理处理器。方便的是，这种扩展工作可以用于 CMP 系统。此处描述的技术对于大型 SMP 扩展至关重要，现在即使对于入门级 CMP 系统也是必需的。在未来五年内，预计 CMP 硬件将扩展到每个系统多达 512 个处理器线程，从而将操作系统扩展的要求推向今天实现的极限之外。

操作系统利用率指标

在具有多线程内核的系统上报告处理器利用率提出了一个挑战。在单核芯片中，吞吐量通常与处理器利用率成比例地增加。在多线程芯片中，硬件线程之间共享资源的机会更大，因此吞吐量与处理器的实际利用率之间存在非线性关系。因此，基于报告的处理器利用率计算“余量”可能不再准确。

例如，具有两个线程的处理器内核（例如 Intel Xeon）在操作系统看来是两个独立的处理器。如果一个软件线程完全使用其中一个线程，而另一个线程完全空闲，则处理器将显示 50% 的繁忙，并由操作系统报告为如此。在 Xeon 体系结构上运行这两个线程通常可能仅产生 10% 的吞吐量增加，但由于两个线程都被利用，它将报告为 100% 繁忙。因此，当系统达到最大吞吐量的 90% 时，现在报告的利用率为 50%。

这种效果将因处理器内硬件线程共享的资源数量而异，最终将需要重新定义系统利用率指标的含义，以及一些新的报告设施。容量规划方法论的影响也需要考虑。

利用虚拟化实现并行性

到目前为止，我们已经研究了如何通过扩展单个应用程序或操作系统来找到使用 CMT 可用的许多硬件线程的方法。有效利用这些资源的另一种方法是同时运行多个不可扩展的应用程序，甚至运行几个未优化的操作系统，使用操作系统或服务器虚拟化等技术。

这些设施通常允许将应用程序的多个实例整合到单个服务器上（参见图 6）。

例如，Solaris Container 设施允许多个应用程序驻留在单个操作系统实例中。在这种环境中，您可以随着应用程序的添加来利用累积的并发性。通过添加两个 Web 服务器，每个服务器具有 16 个线程的并发性，您可以将系统范围的并发性潜在地提高到 32 个线程。这种副作用提供了一种有用的机制，使您能够以可以利用 CMP 系统的全部并发性的方式部署可扩展性有限的应用程序。

另一种相关的虚拟化技术是虚拟机环境，它允许在单个硬件平台上运行多个操作系统实例。虚拟机技术的示例包括 VMware 和 Xen。这些环境允许在单个系统上整合应用程序和操作系统，这提供了一种在 CMP 体系结构上部署甚至不可扩展的操作系统（尽管稍微复杂一些）的机制。

CMP 需要开发人员重新思考

CMP 系统的引入代表着以新的维度扩展系统的重大机遇。CMP 系统最显著的影响在于扩展规模的数量级提升：曾经被认为是低端的单处理器或双处理器入门级系统，现在应被视为 16 路到 32 路系统，而且很快，即使是中端系统也将扩展到数百路。

对于应用程序开发者而言，这意味着对应用程序内部机器可扩展性的新的或修订的关注，以及对软件许可费用计算方式的重新思考。对于操作系统开发者而言，扩展到数百路将成为一项要求。对于部署实践者而言，CMP 代表了一种扩展应用程序的新方法，并且需要在我们构建的系统、我们调整的方式以及我们用于容量规划的技术中加以考虑。

参考文献

1. AMD Opteron 处理器； http://www.amd.com。

2. Kongetira, P., Aingaran, K., 和 Olukotun, K. 2005. Niagara: 一款 32 路多线程 SPARC 处理器。《IEEE Micro》 25 (2): 21–29。

3. Amdahl, G. M. 1967. 单处理器方法实现大规模计算能力的有效性。《AFIPS 会议论文集》: 483-485。

4. FreeBSD SMP 项目； https://freebsd.ac.cn/smp/。

5. Bonwick, J. 1994. Slab 分配器：一种对象缓存的内核内存分配器。Sun Microsystems。

6. Bonwick, J., 和 Adams, J. 2001. Magazines 和 Vmem：将 Slab 分配器扩展到多个 CPU 和任意资源。Sun Microsystems 和加州理工学院。

7. Kleiman, S., 和 Eykholt, J. 1995. 中断作为线程。《 Sigops 操作系统评论》 29 (2): 21-26。

8. Tripathi, S. 2005. Solaris 操作系统网络性能。Sun 白皮书（二月）。

9. Cantrill, B. M., Shapiro, M. W., Leventhal, A.H. 2004. 生产系统的动态检测。《Usenix 会议论文集》。

最初发表于 Queue 杂志第 3 卷，第 7 期—
在数字图书馆中查看此项目

Richard McDougall，如果他生活在 100 年前，肯定会打开第一辆四冲程内燃汽油动力汽车的引擎盖，探索改进的新技术。他会寻找解决复杂问题的简单方法，并帮助先驱车主了解技术如何运作，从而最大限度地利用他们的全新体验。如今，McDougall 利用技术来满足他的好奇心。他是 Sun Microsystems 的杰出工程师，专门研究操作系统技术和系统性能。McDougall 是《Solaris Internals》（Prentice Hall，2000 年；第二版，2005 年）和《Resource Management》（Prentice Hall，1999 年）的作者。

有关更多信息，请参阅数字图书馆中 Richard McDougall 的作者页面：Richard McDougall

最初发表于 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 实现专用且固定的功能，并提供最佳的功耗和性能特性，但任何功能更改都需要对电路进行完全（且极其昂贵的）重新设计。