568
社区成员
发帖
与我相关
我的任务
分享在移动平台上最大程度地节省功率
随着代码为 Yonah（英特尔® 酷睿™ 双核）的移动式处理器的启动，英特尔在移动市场领域率先引入了双核处理器。由于系统中执行资源的可用性加倍了，因此预计许多应用程序会采用多线程，进而充分利用可用的 CPU 资源。
对于移动平台，功能消耗始终是极具重要性的主要方面之一。使用多线程应用程序，可以比使用单线程应用程序更快地完成手头的工作。因此，提高性能可以节省功率，因为与单线程版本相比，使用系统资源的时间将更少。
对应用程序进行多线程处理还会引入其他注意事项，如当应用程序中的线程不均衡（一个线程比其他线程所做的工作多出很多）时对功率/性能的影响、线程的 CPU 使用情况中的差异（例如，一个线程可能会消耗 100% 的 CPU，而其他线程可能消耗 10-20% 的 CPU），以及何时将线程与单核关联，而不是在单独的核上运行线程。在这里，我们将使用各种多线程应用程序和多任务方案研究这类问题，并开发在对应用程序进行多线程处理时应该考虑的建议。
此处介绍的所有测试都是在具有 Napa 平台的双核 Yonah（英特尔酷睿双核）工程样例系统上执行的。功率测量是使用 Fluke NetDAQ* 完成的。
此处突出了各种应用程序（单线程和多线程实现）以及内部开发的测试内核的特征，可将其用于功率/性能测量。这些应用程序包括各种内容创建应用程序、游戏空间中的内核、使用英特尔® 集成性能基元 (IPP) 的内核以及办公生产率应用程序。
此处论述的应用程序的单线程和多线程实现是使用 Microsoft Windows* 提供的两个功率方案进行测试的。这样一来，就可以采用 CPU 全频或在启用节能功能的情况下运行应用程序。与采用 CPU 全频运行相比，使用这些功率方案进行测量将有助于了解在启用了节能功能时对性能和功率的影响。
在节能（“自适应”）模式下运行系统时（如下文所述），英特尔 SpeedStep® 动态节能技术将减少平台上的功率消耗，并增强笔记本电脑的电池使用寿命。SpeedStep 动态节能技术可以在 CPU 使用率很低的情况下降低处理器的核电压和时钟频率，进而在无需用户干预的情况下实现节能。请注意，只有当系统在 Microsoft Windows* XP 上采用节能（自适应）模式运行时，SpeedStep 动态节能技术才有效。
MaxPerf：又称为一直开着 (AO) 模式。此功率方案提供最强的性能。使用此功率方案的处理器以最大可用频率运行，性能高于电池寿命。
自适应：也称为便携/袖珍式 (PL) 模式。此功率方案经过优化，可以增加电池使用寿命。处理器频率状态随着处理器的工作负荷发生变化，电池寿命高于性能。当系统处于空闲状态时，处理器以最低的处理器频率状态运行，进而达到节能目的。操作系统使用英特尔 SpeedStep 动态节能技术更改处理器频率状态。
详细论述各种实验之前，我们将在下一部分中提供有关 Microsoft Windows 上的线程调度机制和各种线程模型的背景信息。
线程调度
在多处理器系统上，操作系统通常根据任何给定时间的系统活动在不同的处理器上调度线程。当处理器处于空闲状态时，通常使用调度算法在此处理器上调度线程。新线程准备就绪可供执行时，将根据处理器可用性以及新线程的优先级在调度该线程后直接执行或将其置于就绪的队列中。如果应用程序没有为特定的处理器/核指定“硬关联”（此处称为“关联”），则操作系统调度程序将使用其调度算法在任何可用处理器上调度线程。Microsoft 提供的 API 将线程与某个特定处理器 (SetThreadAffinityMask()) 关联，这指明仅在指示的处理器上执行该线程，即使其他处理器处于空闲状态，也是如此。使用关联可能会导致性能降低，因为关联的线程在等待指定的处理器时可能会被停止，即使系统中的其他处理器处于空闲状态，也是如此。为解决此问题，Microsoft 引入了另一个 API（即 SetIdealProcessor()），这样开发人员可以为操作系统提供有关应首选哪个处理器来执行特定线程的提示。但是，如果首选的处理器不可用，则操作系统会使用调度算法从其他可用的处理器中进行选择。下面的“结果”部分展示了通过将一个或多个线程与单核相关联而进行的研究，可帮助您了解对功率/性能特征的影响。
线程模型
从本质上将，有两种类别的线程模型：
数据域分解：在此模型中，可用的数据集被分成不同的部分，而且每个线程都在其各个部分中工作。在同步点，线程可以将其各自的工作部分组合在一起。由于每个线程使用不同的数据集执行相同的工作，因此，如果对源代码进行任何更改，此线程模型不大可能对性能有任何影响。在这种情况下所做的更改对两个线程的影响程度是一样的。例如，用两个线程各处理一半可用数据集的数据处理应用程序将对其各自的数据集执行类似的指令。对代码库（新增的用于筛选某些数据的功能）所做的任何更改对两个线程的影响程度都相同，因为这两个线程必须通过该新功能运行。因此，多线程性能不大可能会受到更改的影响。
功能域分解：在此模型中，每个线程都在应用程序内的各个代码功能块/段中工作。在同步点，线程通常会将其各自的工作项目组合起来。在这种情况下，由于每个线程都在应用程序内的各个代码段中工作，因此在一个或多个代码段中所做的更改可能会对性能造成严重影响。例如，如果上面论述的数据处理应用程序使用以下方式进行多线程处理，即，一个线程执行数据收集阶段，而另一个线程执行数据处理阶段，则对数据处理（新增的用于筛选某些数据的功能）所做的任何更改都可能会导致两个线程间出现失衡情况，因为数据处理线程运行的时间可能会更长。因此，在这种情况下所做的更改可能会对多线程性能产生影响。
除了数据和功能分解以外，还可以将线程模型进一步分为均衡和不均衡线程类别。
均衡线程模型：在这种情况下，每个线程都与应用程序的其他活动线程具有等量的工作。均衡线程的一个示例就是数据处理应用程序（已在上面的“数据域分解”部分中论述了），其中的两个线程通过对其各自的数据集执行类似的指令，分别处理可用数据集的一半。这是开发人员的工作，目的是确保不同线程处理的数据之间没有相关性。数据相关性需要使用同步对象，这会严重降低性能，从而通过使用多线程技术会使得性能改进程度最低。应该始终在线程之间执行最少的同步操作。均衡线程模型产生的效果通常会比不均衡模型产生的效果更好。
不均衡线程模型：在这种情况下，应用程序内每个线程所执行的工作量有显著差异。按照上面的“功能域分解”部分中论述的示例，如果数据处理应用程序中的数据收集阶段比数据处理阶段所用的时间更少，则会产生线程不均衡情况。一般情况下，功能线程模型往往会在应用程序中创建不均衡线程，因为每个线程都在不同的代码段中工作，因此可能会导致一个线程比其他线程完成的速度要快。这可能会减少运行并行代码所用的时间，但可能会导致应用程序中出现不均衡情况。
下一部分论述应用程序使用上面论述的一种或多种线程技术执行多线程处理的功率/性能结果。
本部分中的图形论述了运行 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：均衡线程 - 平台功率（自适应）
正如所指示的那样，与运行单线程版本相比，运行多线程版本的应用程序所消耗的平台功率更低。
对于移动平台，功能消耗始终是极具重要性的主要方面之一。使用多线程应用程序，可以比使用单线程应用程序更快地完成手头的工作。因此，提高性能可以节省功率，因为与单线程版本相比，使用系统资源的时间将更少。
对应用程序进行多线程处理还会引入其他注意事项，如当应用程序中的线程不均衡（一个线程比其他线程所做的工作多出很多）时对功率/性能的影响、线程的 CPU 使用情况中的差异（例如，一个线程可能会消耗 100% 的 CPU，而其他线程可能消耗 10-20% 的 CPU），以及何时将线程与单核关联，而不是在单独的核上运行线程。在这里，我们将使用各种多线程应用程序和多任务方案研究这类问题，并开发在对应用程序进行多线程处理时应该考虑的建议。
此处介绍的所有测试都是在具有 Napa 平台的双核 Yonah（英特尔酷睿双核）工程样例系统上执行的。功率测量是使用 Fluke NetDAQ* 完成的。
此处突出了各种应用程序（单线程和多线程实现）以及内部开发的测试内核的特征，可将其用于功率/性能测量。这些应用程序包括各种内容创建应用程序、游戏空间中的内核、使用英特尔® 集成性能基元 (IPP) 的内核以及办公生产率应用程序。
此处论述的应用程序的单线程和多线程实现是使用 Microsoft Windows* 提供的两个功率方案进行测试的。这样一来，就可以采用 CPU 全频或在启用节能功能的情况下运行应用程序。与采用 CPU 全频运行相比，使用这些功率方案进行测量将有助于了解在启用了节能功能时对性能和功率的影响。
在节能（“自适应”）模式下运行系统时（如下文所述），英特尔 SpeedStep® 动态节能技术将减少平台上的功率消耗，并增强笔记本电脑的电池使用寿命。SpeedStep 动态节能技术可以在 CPU 使用率很低的情况下降低处理器的核电压和时钟频率，进而在无需用户干预的情况下实现节能。请注意，只有当系统在 Microsoft Windows* XP 上采用节能（自适应）模式运行时，SpeedStep 动态节能技术才有效。
MaxPerf：又称为一直开着 (AO) 模式。此功率方案提供最强的性能。使用此功率方案的处理器以最大可用频率运行，性能高于电池寿命。
自适应：也称为便携/袖珍式 (PL) 模式。此功率方案经过优化，可以增加电池使用寿命。处理器频率状态随着处理器的工作负荷发生变化，电池寿命高于性能。当系统处于空闲状态时，处理器以最低的处理器频率状态运行，进而达到节能目的。操作系统使用英特尔 SpeedStep 动态节能技术更改处理器频率状态。
详细论述各种实验之前，我们将在下一部分中提供有关 Microsoft Windows 上的线程调度机制和各种线程模型的背景信息。
线程调度
在多处理器系统上，操作系统通常根据任何给定时间的系统活动在不同的处理器上调度线程。当处理器处于空闲状态时，通常使用调度算法在此处理器上调度线程。新线程准备就绪可供执行时，将根据处理器可用性以及新线程的优先级在调度该线程后直接执行或将其置于就绪的队列中。如果应用程序没有为特定的处理器/核指定“硬关联”（此处称为“关联”），则操作系统调度程序将使用其调度算法在任何可用处理器上调度线程。Microsoft 提供的 API 将线程与某个特定处理器 (SetThreadAffinityMask()) 关联，这指明仅在指示的处理器上执行该线程，即使其他处理器处于空闲状态，也是如此。使用关联可能会导致性能降低，因为关联的线程在等待指定的处理器时可能会被停止，即使系统中的其他处理器处于空闲状态，也是如此。为解决此问题，Microsoft 引入了另一个 API（即 SetIdealProcessor()），这样开发人员可以为操作系统提供有关应首选哪个处理器来执行特定线程的提示。但是，如果首选的处理器不可用，则操作系统会使用调度算法从其他可用的处理器中进行选择。下面的“结果”部分展示了通过将一个或多个线程与单核相关联而进行的研究，可帮助您了解对功率/性能特征的影响。
线程模型
从本质上将，有两种类别的线程模型：
数据域分解：在此模型中，可用的数据集被分成不同的部分，而且每个线程都在其各个部分中工作。在同步点，线程可以将其各自的工作部分组合在一起。由于每个线程使用不同的数据集执行相同的工作，因此，如果对源代码进行任何更改，此线程模型不大可能对性能有任何影响。在这种情况下所做的更改对两个线程的影响程度是一样的。例如，用两个线程各处理一半可用数据集的数据处理应用程序将对其各自的数据集执行类似的指令。对代码库（新增的用于筛选某些数据的功能）所做的任何更改对两个线程的影响程度都相同，因为这两个线程必须通过该新功能运行。因此，多线程性能不大可能会受到更改的影响。
功能域分解：在此模型中，每个线程都在应用程序内的各个代码功能块/段中工作。在同步点，线程通常会将其各自的工作项目组合起来。在这种情况下，由于每个线程都在应用程序内的各个代码段中工作，因此在一个或多个代码段中所做的更改可能会对性能造成严重影响。例如，如果上面论述的数据处理应用程序使用以下方式进行多线程处理，即，一个线程执行数据收集阶段，而另一个线程执行数据处理阶段，则对数据处理（新增的用于筛选某些数据的功能）所做的任何更改都可能会导致两个线程间出现失衡情况，因为数据处理线程运行的时间可能会更长。因此，在这种情况下所做的更改可能会对多线程性能产生影响。
除了数据和功能分解以外，还可以将线程模型进一步分为均衡和不均衡线程类别。
均衡线程模型：在这种情况下，每个线程都与应用程序的其他活动线程具有等量的工作。均衡线程的一个示例就是数据处理应用程序（已在上面的“数据域分解”部分中论述了），其中的两个线程通过对其各自的数据集执行类似的指令，分别处理可用数据集的一半。这是开发人员的工作，目的是确保不同线程处理的数据之间没有相关性。数据相关性需要使用同步对象，这会严重降低性能，从而通过使用多线程技术会使得性能改进程度最低。应该始终在线程之间执行最少的同步操作。均衡线程模型产生的效果通常会比不均衡模型产生的效果更好。
不均衡线程模型：在这种情况下，应用程序内每个线程所执行的工作量有显著差异。按照上面的“功能域分解”部分中论述的示例，如果数据处理应用程序中的数据收集阶段比数据处理阶段所用的时间更少，则会产生线程不均衡情况。一般情况下，功能线程模型往往会在应用程序中创建不均衡线程，因为每个线程都在不同的代码段中工作，因此可能会导致一个线程比其他线程完成的速度要快。这可能会减少运行并行代码所用的时间，但可能会导致应用程序中出现不均衡情况。
下一部分论述应用程序使用上面论述的一种或多种线程技术执行多线程处理的功率/性能结果。
本部分中的图形论述了运行 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：均衡线程 - 平台功率（自适应）
正如所指示的那样，与运行单线程版本相比，运行多线程版本的应用程序所消耗的平台功率更低。
...全文
请发表友善的回复…
发表回复
formajia3 2008-09-24
- 打赏
- 举报
潜水多年，今日上岸，继续学习。
pengzhenwanli 2007-03-22
- 打赏
- 举报
学习学习
lidongri 2007-03-21
- 打赏
- 举报
大家好才事真的好
iu_81 2007-03-21
- 打赏
- 举报
mark
YuLimin 2007-03-21
- 打赏
- 举报
好是好，价格降下来才是真的好啊！
xiaoyao888 2007-03-21
- 打赏
- 举报
学习
子陌红尘 2007-03-21
- 打赏
- 举报
进来看看
nancun 2007-03-21
- 打赏
- 举报
捧个场
yiluzoulai 2007-03-21
- 打赏
- 举报
不错哦，谢谢共享
约翰羊 2007-03-21
- 打赏
- 举报
虽然有些晕,但大概看懂了
yqwaxyq 2007-03-21
- 打赏
- 举报
了解一下
mobilecoder 2007-03-15
- 打赏
- 举报
嘿嘿，捧个场
syf7901 2007-03-15
- 打赏
- 举报
不错.学习了
chengyongli 2007-03-14
- 打赏
- 举报
具有不均衡线程模型的应用程序
正如上文所述，与运行单线程版本相比，使用均衡多线程处理不仅可以提高性能而且会节能。在此部分，我们将检查具有不均衡线程模型的应用程序的功率/性能情况。为进行此研究，我们创建了一个样例游戏物理引擎（使用 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：多任务方案 - 平台功率
总结/建议
正确执行线程可以提高性能并节能。
正如“均衡多线程模型”部分中的数据所示，正确执行多线程处理的应用程序不仅性能得到提高，而且节能。这包括具备最少不均衡和同步点的多线程实现。对应用程序执行多线程处理时，始终建议使用的线程模型中的所有线程都独立执行等量的工作。在线程之间最小化同步点将导致在并行部分花费更多时间，这最终会转变为性能提高和节能。
与均衡线程相比，线程不均衡可能会导致性能降低，而且可能不会提供功率/性能优势。
正如“不均衡线程模型”部分中论述的那样，与均衡线程模型相比，使用不均衡线程模型的应用程序的性能提高比较少；因此与均衡实现方案相比，消耗的功率更大。线程不均衡可能会导致线程在核之间发生经常性迁移，这可能会导致报告不正确的处理器活动状态。这可能会使处理器在自适应方案下降至较低的频率状态（如果未启用 Microsoft 提供的修复程序），即使某个线程正在利用全处理器资源，也是如此。采用自适应模式在双核系统中运行单线程应用程序时，可能也会出现此问题。
使用 Microsoft 提供的 GV3 修复程序 (KB896256)
如果多线程应用程序在自适应 (PL) 模式下出现性能降低/功率消耗增加的情况，请安装 Microsoft 提供的 GV3 修复程序；该问题可能是操作系统在自适应模式下时正在获取不正确的处理器性能相关信息。GV3 修复程序将跟踪整个包（而不是各个核）中的 CPU 使用情况，并将使操作系统以最佳的频率运行。
操作系统调度与硬关联
一般情况下，对于英特尔酷睿双核系统，建议使用操作系统调度，而不要关联线程或应用程序。操作系统调度程序将使用任何未充分使用的核；而硬关联可能会降低性能，因为应用程序可能需要等待特定处理器可用为止，即使系统中的其他处理器处于空闲状态，也是如此。
由于有图片，所以将原文地址帖上来：http://www.intel.com/cd/ids/developer/apac/zho/325671.htm?page=1
正如上文所述，与运行单线程版本相比，使用均衡多线程处理不仅可以提高性能而且会节能。在此部分，我们将检查具有不均衡线程模型的应用程序的功率/性能情况。为进行此研究，我们创建了一个样例游戏物理引擎（使用 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：多任务方案 - 平台功率
总结/建议
正确执行线程可以提高性能并节能。
正如“均衡多线程模型”部分中的数据所示，正确执行多线程处理的应用程序不仅性能得到提高，而且节能。这包括具备最少不均衡和同步点的多线程实现。对应用程序执行多线程处理时，始终建议使用的线程模型中的所有线程都独立执行等量的工作。在线程之间最小化同步点将导致在并行部分花费更多时间，这最终会转变为性能提高和节能。
与均衡线程相比，线程不均衡可能会导致性能降低，而且可能不会提供功率/性能优势。
正如“不均衡线程模型”部分中论述的那样，与均衡线程模型相比，使用不均衡线程模型的应用程序的性能提高比较少；因此与均衡实现方案相比，消耗的功率更大。线程不均衡可能会导致线程在核之间发生经常性迁移，这可能会导致报告不正确的处理器活动状态。这可能会使处理器在自适应方案下降至较低的频率状态（如果未启用 Microsoft 提供的修复程序），即使某个线程正在利用全处理器资源，也是如此。采用自适应模式在双核系统中运行单线程应用程序时，可能也会出现此问题。
使用 Microsoft 提供的 GV3 修复程序 (KB896256)
如果多线程应用程序在自适应 (PL) 模式下出现性能降低/功率消耗增加的情况，请安装 Microsoft 提供的 GV3 修复程序；该问题可能是操作系统在自适应模式下时正在获取不正确的处理器性能相关信息。GV3 修复程序将跟踪整个包（而不是各个核）中的 CPU 使用情况，并将使操作系统以最佳的频率运行。
操作系统调度与硬关联
一般情况下，对于英特尔酷睿双核系统，建议使用操作系统调度，而不要关联线程或应用程序。操作系统调度程序将使用任何未充分使用的核；而硬关联可能会降低性能，因为应用程序可能需要等待特定处理器可用为止，即使系统中的其他处理器处于空闲状态，也是如此。
由于有图片，所以将原文地址帖上来：http://www.intel.com/cd/ids/developer/apac/zho/325671.htm?page=1
