本部分中的图形论述了运行 Windows* XP 的英特尔酷睿双核 (Yonah) 工程样例系统的功率/性能结果。数字以“秒”为单位。功率测量是使用 Fluke NetDAQ 执行的，该产品报告的平均功率（以瓦特 (W) 为单位）随后将使用应用程序运行时数据 (mWHr) 转换为总功率。
具有均衡线程模型的应用程序正如第 3 页的“均衡线程模型”部分中论述的那样，这类应用程序中的线程通常执行几乎等量的工作，而且消耗等量的处理资源。此处研究的应用程序通常是 CPU 密集的，消耗 95-100% 的 CPU。在这里，我们将论述当这类应用程序在单线程和多线程模式（分别简称为 ST 和 MT）下运行时的性能和功能影响。性能数据的测量单位为秒，后面是 CPU 功率消耗数据以及平台功率消耗数据（测量单位为 mWHr）。
图 1 中的图表指示了用于运行 ST 和 MT 版本的应用程序的性能数据。加密和视频编码应用程序具有两种 MT 实现，因此结果如 MT-1 和 MT-2 所示。对于内容创建应用程序，仅使用一种实现（如 MT-1 所示）执行多线程。
点击查看大图图 1：均衡线程性能如图 1 所示, 多线程应用程序清楚地显示了通过运行单线程版本显著提高了性能。例如，ST 版本的加密需要用 50 秒才能完成，而 MT-1 和 MT-2 版本只需 25 秒。
现在，让我们检查一下多线程对功率消耗的影响。图 2 和 3 分别指示了自适应（便携/袖珍式）模式的 CPU 和平台功率。选择自适应模式的原因在于，它会按需动态更改 CPU 频率，从而加大功率消耗。
对于每个应用程序运行（ST 和 MT），将对功率数据收集进行标准化，使得达到最长的运行时。例如，如图 1 所示，加密工作负荷在 ST 模式下运行 50 秒，在 MT 模式下运行 25 秒。无论是在 ST 还是 MT 情况下，测量功率数据都用了 50 秒。此处的目的是确定是否可以通过以更快地速度完成 CPU 密集型任务（如在 MT 情况下）并在剩余持续时间内转至空闲状态来节省功率。
图 2：均衡线程 - CPU 功率（自适应）如图 2 所示，节能是通过更快地完成工作 (MT) 并按照 ST 版本在剩余的时间内处于空闲状态来实现的。这表明，正确完成多线程处理不仅会提高性能，而且还会达到节能目的。例如，加密 ST 版本运行 50 秒将消耗总功率的 150 mWHr，而运行 25 秒加密 MT 版本并在剩余的 25 秒使系统处于空闲状态将消耗总功率的 110 mWHr。因此，多线程处理有助于节能。
图 3 中的图表指示了多线程处理对平台功率的影响。
图 3：均衡线程 - 平台功率（自适应）正如所指示的那样，与运行单线程版本相比，运行多线程版本的应用程序所消耗的平台功率更低。
具有不均衡线程模型的应用程序正如上文所述，与运行单线程版本相比，使用均衡多线程处理不仅可以提高性能而且会节能。在此部分，我们将检查具有不均衡线程模型的应用程序的功率/性能情况。为进行此研究，我们创建了一个样例游戏物理引擎（使用 Microsoft DirectX*）。该样例应用程序具有两部分：1) 物理计算（图形对象的碰撞检测和消解），以及
2) 渲染（将更新的位置绘制在屏幕上）。应用程序的设计是缜密的，因此可针对 CMP 处理器来研究均衡和不均衡线程处理。简而言之：
- 均衡：对于此实现方案，将图形对象（和背景图像）分成两部分，每个线程处理其各自对象集的碰撞检测和消解。
- 不均衡：在此实现方案中，一个线程的任务是执行碰撞对象的碰撞检测和消解，而其他线程的任务是计算更新的位置。结果是实现了第一个线程比第二个线程更具 CPU 密集型特征的设计目标。
在这里，创建两个多线程实现方案隐含的意图是，与均衡线程模型相比，在使用不均衡线程模型时评估功率/性能影响。
下面显示了使用这两种实现方案时的不同功率方案（MaxPerf 和自适应）中的性能数据。现在，让我们集中关注前两个数据集（MaxPerf 和自适应 - 默认）。
图 4：不均衡线程性能正如上面图表中的前两个数据集所示，不均衡多线程实现方案（不均衡 MT）的性能从 MaxPerf 模式下的 64 秒降至自适应模式下的 120 秒（包围条的圆所示）。
现在，让我们来看看由于这类性能降低平台功率消耗会发生什么情况。此处论述的功率测量是使用“均衡线程模型”部分提到的技术进行标准化的。
图 5：不均衡线程 - 平台功率正如上面的图表所示（图 5），平台功率消耗会因自适应 (PL) 模式（默认）下性能的降低而增加。由于现在完成“不均衡 MT”工作负荷所用的时间长了很多，因此导致性能降低，功率消耗增加。
在运行不均衡 MT 版本的同时查看应用程序配置文件，可以看到，因为只有一个线程执行大量工作，因此第一个线程在核之间不断迁移，使得核中的有效 CPU 使用率达到 50%。这是 Windows 调度程序工作方式的自然结果。但是，在以自适应（便携/袖珍式）功率模式运行的系统中，此线程迁移会导致 Windows 内核功率管理器不正确地计算处理器的最佳目标性能状态，因为与整个包相比，各个核可能不是很忙。由于此原因，Windows 操作系统往往会降低处理器频率，以采用自适应模式节能；因此在自适应模式下，性能结果可能会呈现降低趋势。反过来，这将会导致功率消耗的增加。
为了解决不正确计算最佳频率的问题，Microsoft 提供了一个修复程序 (KB896256)，该程序用于更改内核功率管理器以跟踪整个包（而不是各个核）中的 CPU 使用情况，进而计算应用程序的最佳频率。因此，即使线程不断迁移，也应通过查看整个包（具有两个核）而不是各个核做出降低 CPU 频率的决定。
图 4 中的第三个数据集指示了使用内核修复程序时的数据。在这种情况下，自适应 (PL) 模式下的不均衡 MT 实现方案显示了与 MaxPerf (AO) 模式的实现方案类似的功率/性能数据。修复后，处理器可以采用最佳频率运行，而不会导致在自适应 (PL) 模式下时性能降低。修复后的平台功率数据显示在图 5 中的“自适应 (PL) - 包含 GV3 修复”列。
此研究表明，不均衡线程模型/未充分使用的 CPU 可能会导致性能降低，进而导致功率消耗增加。建议在对应用程序执行多线程处理时使用均衡线程模型。可使用 Microsoft Perfmon*、英特尔® VTune™和英特尔® 线程工具（例如英特尔® 线程检测器和英特尔® 线程性能分析器）提供的时间线视图等工具来识别线程不平衡，进而跟踪各个线程运行时和处理器使用计数器。
将一个应用程序关联到单个核的多任务方案针对 PC 用户的常见使用方案之一是同时运行多个应用程序（即多任务）。为了解同时运行两个应用程序的性能和功率影响，可以做一个实验，即让两个办公生产率应用程序并发运行。由于使用不同的技术调度两个应用程序可能会显示功率/性能影响，因此在此处将检查以下方案：
- Microsoft Windows XP 使用其调度算法调度两个应用程序（无关联）
- 每个应用程序与每个核都进行硬关联。应用程序 1 在核 0 上运行，应用程序 2 在核 1 上运行。
- 一个应用程序与核 0 硬关联，而 Windows XP 调度另一个应用程序
选择这些调度配置的目的是识别某种特定调度机制与其他调度机制相比，是否更能促进节能和性能提高。
这些配置的性能数据显示在下面的图 6 中。正如图表所示，使用不同的调度配置时看不出任何显著的性能差异。
图 6：多任务方案性能如图 7 所示，CPU 功率消耗数据（将两个应用程序与各个核相关联的第二种方案）展现的功率消耗情况与 Windows XP 调度相比稍高一些。
图 7：多任务方案 - CPU 功率在平台功率消耗中显示（图 8）了类似的影响，在这类情况下，将应用程序与每个核硬关联起来后，显示的平台功率消耗情况与让 Windows XP 执行调度相比稍高一些。
图 8：多任务方案 - 平台功率
