Pentium4 性能监测单元

 

 

翻译： 秦白衣  

Qinchenggang@sict.ac.cn

欢迎读到此文而有疑问的朋友来信探讨。

 

         Intel Pentium4的性能监测功能克服了之前处理器中发现的很多限制和问题。Pentium 4 Xeon处理器的性能监测单元支持多线程。

         大多数现代高性能处理器都具有能够监测性能的片上硬件单元。这种硬件单元通常包括事件探测器(Event Detector)与计数器，可以区分不同特权模式（Privilege Mode）下的性能事件，同时还支持基于事件的采样。在以往的处理器中，性能监测单元具有若干不足，比如计数器数量过少，不能区分猜测相关的事件与猜测无关的事件，基于事件的采样不精确等问题。在推出Pentium4处理器之后，Intel克服了先前处理器在性能监测单元上的若干不足。Pentium 4支持48个事件探测器和18个事件计数器。相比于其它的处理器，Pentium 4能够同时记录更多的性能事件。Pentium 4还提供了几种指令标签（Instruction-tagging）机制，可以记录非猜测执行（nonspeculative）的性能事件（这些事件由引退指令引发）。为了改进不精确的事件采样（IEBS），Pentium4提供了精确的事件采样机制（PEBS），该机制可以精确地辨别出引发某个性能事件的指令。PEBS使得用户能够分析各种存储相关事件的数据及其地址。因为Pentium 4 Xeon是X86体系结构中第一款支持同时多线程（SMT）的处理器，它的性能监测单元能够关联线程ID与事件，分别记录与各个线程相关的事件，并且能够记录不同线程模式（Thread Mode）下的性能事件。

事件侦测器与计数器

         Pentium 4的晶体管数量超过4200万个，其规模远大于它的祖先Pentium 3，Pentium 3仅拥有2800个晶体管。Pentium 4的设计规模是空前的，Intel先前对性能事件侦测器与计数器的布局方法已不能继续使用。在先前的设计中，事件侦测器在芯片上的分布比较分散，一般位于相关的硬件单元附近；事件计数器则集中位于中央区域。这种布局需要将所有的计数信号路由到位于中央区域的事件计数器上。

         如果在Pentium 4的设计中继续采用上述布局，则需要花费更多的芯片区域来实现事件计数总线到事件计数器的路由。Intel计算机体系结构的专家们提出了2种替代方案：将计数器放置在各个事件侦测器的旁边，或者将各个计数器模块分散在芯片的不同位置，并使得在位置上比较接近的事件侦测器能够共享这些计数器。第一种方法可以消除事件侦测器与计数器间的信号路由，同时为每个事件侦测器都提供了一个事件计数器。第二种方法可以降低事件侦测器与事件计数器间路由的复杂度，因为事件侦测器与计数器模块距离更近了。第一种方法消除了路由开销，还为用户提供了更多可以并行使用的计数器。但是，相比较第二种方案，为每个事件侦测器都提供一个事件计数器会占用更大的芯片面积。Intel的计算机体系结构的专家也更倾向于后者。

结构和功能

         图1显示了事件侦测器与计数器组的结构与功能。图1描述了Pentium4中典型的功能单元，如分支预测单元或者Cache追踪单元。以成对的方式实现事件侦测器可以在同时多线程系统中并发地为不同的线程记录同一个性能事件。大多数功能单元都拥有一对具有相同的事件侦测器。Checker/Retire单元除外，它拥有3对事件侦测器。

         每个事件侦测器都有最大带宽为4bits的输出总线，每个周期可以输出的最大增量为15。Pentium4将每个事件侦测器的输出总线路由到一个事件计数器组上。大多数事件计数器组都具有4个计数器，但是不包括指令队列单元中的计数器组，因为它拥有6个计数器。每个计数器组有2个输出信号，用来在计数器溢出时触发中断，满足EBS的需要。在这种结构下，多个事件侦测器共享同一组计数器（4个或6个）。因此这些计数器组仅能同时记录4个（或6个）事件。

 

图1. Pentium 4的事件侦测器与计数器的结构。通过事件侦测器可以选择需监测的事件，并且区分事件的特权级别（OS模式还是用户模式）和线程ID。每个Pentium4中的功能单元都包含2个或者6个事件侦测器。每个事件计数器组（counter block）包含4个或6个计数器，每个计数器都可以关联一个事件侦测器。事件侦测器可以执行阈值比较或沿监测，并且根据线程模式进行事件计数。计数器组中的计数器可以在溢出时触发一个性监测中断。

 

         通过事件侦测器可以选择一个事件并设置事件属性，可以分别记录不同特权级与线程ID下发生的事件。事件计数器支持阈值比较（Threshold Comparison），沿侦测，还可以区分线程模式。为了支持EBS，它们还能在溢出时产生性能监测中断（这是一个NMI中断）。用户可以通过事件选择控制寄存器（ESCRs：event select control registers）和计数器配置控制寄存器（CCCRs：counter configuration control registers）配置计数器的属性。

图2. 事件侦测器与事件选择控制寄存器（ESCRs）的互联，以及相应的计数器和计数器配置控制寄存器（CCCRs）。

组（使用同一组计数器的事件侦测器）

         图2显示了pentium4中的4组事件侦测器与计数器。每组都包括事件侦测器（包括ESCRs）和一组计数器（包括CCCRs）。设计者根据计数器组对应的Pentium4功能单元为它们命名。例如：BPU,ISTEER, IXLAT，ITLB，PMH，MOB，FSB，以及BSU单元中的事件计数器组均可以根据分支预测单元命名，因为这些单元中的侦测器均连接到BPU中的计数器组上，该计数器组包括4对CCCR和计数器。计数器组中的计数器以成对的方式存在，如BPU组中的计数器0与计数器1。每对计数器共享同一组事件侦测器和ESCR。如图2所示，虽然Pentium4拥有44个事件侦测器，但仅能并行的记录18个事件，因为仅有18个计数器可用。尽管如此，相比其它的处理器而言，能够同时记录18个事件也算一个显著的进步了。

事件选择

图3. 事件选择控制寄存器

         利用图3所示的ESCR，可以配置一个事件侦测器。通过7位的事件选择段可以选择期望监测的事件，16位的事件掩码段可以选择期望事件的子集。例如，Pentium4的branch_retired事件使用了事件掩码段中的4位来确定分支类型：发生、未发生、已预测和预测错误。为了统计被错误预测的分支，用户可以首先选择branch_retired事件，并在事件掩码中设置与branch-taken-mispredicted，以及branch-not-taken-mispredicted对应的位。

         利用ESCR的低4位可以选择事件的特权级别和线程ID。线程ID用以确定记录并发执行的2个线程中的哪一个线程触发的事件。关于Pentium4的SMT特性可以参见后文的：“同时多线程：提高了高性能处理器的指令吞吐量”。例如，为了能够统计两个线程引发的所有的OS事件，用户需要同时设置T0_OS与T1_OS位。选择这4位中的任何一位，便意味着同时选定了特权模式和线程模式，这比使用2位来提供优先级（操作系统或用户）选择，用另2位来提供线程模式（线程1或线程2）的选择提供了更高级别的控制手段。比如，如果用户希望统计线程0的用户事件和线程1的系统事件，仅需设置T0_USR与T1_OS位即可。在将T0，T1，USR，OS模式分成4位实现的情况下，是不可能进行这样的选择的。

计数器配置

图4. 计数器配置控制寄存器

         图4描述了CCCR中的位段布局。

l  使能计数器

l  选择事件侦测器以作为寄存器递增的源

l  根据处理器当前的线程模式进行事件计数

l  配置计数器的阈值以及沿侦测

l  选择在计数器溢出时是否触发中断

l  使能配对计数器的级联

CCCR还具有一个状态位，OVF，用以判断是否发生了溢出。

使用事件计数器时，首先需要使能计数器并且选择提供增量的事件侦测器。通过CCCR的使能位可以打开该计数器，通过ESCR选择位段可以选择该计数器使用的事件侦测器。在图2中，事件侦测器方框中的粗体数字表示，在CCCR的ESCR选择字段中，可以使用该数字选择侦测器。

通过CCCR的比较，增补（Complement），与阈值字段，可以配置该计数器中与阈值侦测相关的信息。在设置了比较位后，计数器将来自事件侦测器的输入值与阈值段中的值进行比较。增补位决定着比较的方式。0表示需进行大于比较；1意味着小于等于比较。当输入值与阈值的比较结果为真时，计数器加1。在使能阈值比较功能后，也可以再通过edge位使能沿侦测功能。如果使能了阈值比较，并且设置了edge位，沿侦测硬件将对比上次阈值比较结果与当前的阈值比较结果。如果前一个阈值比较结果为False，而目前的阈值比较结果为True时，计数器增1，而此时，阈值过滤器将侦测到一个上升沿。

因为Pentium4是第一款实现SMT技术的X86体系结构的处理器，它的性能监测单元当然能够区分出不同线程模式下的性能事件。CCCR中2位宽的线程模式选择位段能够设置在何种线程模式下进行计数。线程模式分为4种：

l  单线程模式：仅有一个线程是活动的，处理器将所有的资源都分配给该线程。

l  双线程模式：两个线程都是活动的，它们共享处理器资源。

l  无线程模式：没有线程是活动的。但是，一些资源必须响应系统中的其它事件，而且这种行为可能会引发性能事件。例如，在一个双处理器系统中，一个处理器处于无线程模式，另外一个处理器处于双线程模式。处于双线程模式的处理器可能会执行一些内存事务，从而使得另外一个无线程模式下的处理器必须执行一些Cache操作。在执行了属主读（read-for-ownership）事务之后，处在无线程模式下的处理器必须修改Cache Line。

l  任意模式：事件计数独立于当前的线程模式。

其它特性

         为了支持EBS，Pentium4的计数器可以在溢出时触发一个中断，当然，必须提前设置CCCR中的OVF_PMI_T0与OVF_PMI_T1位（如图4所示）。在设置了OVF_PMI_T0位后，将在计数器溢出时，触发一个线程0的中断。在设置了OVF_PMI_T1位后，将在计数器溢出时，触发一个线程1的中断。另外，如果设置了FORCE_OVF位，在每次计数器增加时，都认为发生了计数器溢出。如果用户想收集那些不频繁发生的事件的信息，FORCE_OVF位就非常有用了。计数器除了可以在溢出时触发中断，每个CCCR还具有一个OVF位，如果该位为1，便意味着相应的计数器溢出了。在发生中断时，性能监测中断的中断处理函数（ISR）首先检查所有活动CCCR中的OVF位，以判断哪个计数器发生了溢出。注意，与之前的处理器一样，通过这种方式实现的EBS，同样也是不精确的。

         Pentium4支持计数器级联，通过CCCR中的级联位即可实现（见图4）。当2个计数器级联时，其中一个正常计数，另一个仅在第一个计数器发生溢出时才开始计数。也可以通过设置，让第一个计数器在M个事件之后发生溢出，第二个计数器在N个事件之后发生溢出，用户便能够以非常精细的方式收集相关事件的信息。在同一个计数器组中，可以级联不同对的计数器。比如，在BPU中，设置了计数器2的CCCR中的级联位，并且清除了使能位后，便可以在计数器0发生溢出之后，使得计数器2才开始计数。

获得非猜测事件计数

         如果能够辨别出在猜测执行指令时，哪些是引退指令（Retired Instruments，正常结束的指令）引发的事件，哪些是非引退指令（由于猜测错误，这些指令被抛弃了，永远不会引退。）触发的事件，将对性能分析具有非常大的帮助。比如，当分支预测频繁失效时，指令通常不会引退。这些非引退指令可能会大量增加相关事件的计数。这些计数通常会超出仅由引退指令引发的事件的数量。如果不对猜测正确的与猜测错误的事件进行区分，在性能分析时，只能得到不精确的结果。例如，如果一个程序频繁地访问一个很小的数据结构，该结构可以完全放入数据Cache中。程序中的分支指令很频繁，而该分支通常会被错误预测。在预测错误时访问的数据，实际上都是不必要的，但是被访问的数据有可能不在数据Cache中。如果在记录Cache失效次数时，不区分猜测正确与猜测错误的情况，可能会得出严重错误的结论，即程序需要的数据量超出了Cache的容量。这个错误结论可能会导致毫无意义的优化工作，比如调节数据结构的大小，或者访问序列，以改善Cache性能。如果能正确区分猜测正确与猜测错误情况下的事件，程序的分析人员便可以致力于提高分支预测的成功率，或者调节那些在分支预测失效时执行的指令，以避免造成数据Cache失效。

         Pentium4使用标签机制对猜测相关的事件进行计数。（关键是要辨别引退指令与非引退指令）处理器在解码每条X86指令时，都会将该指令拆成一系列微指令的序列。Pentium4的标签机制在微指令引发特殊的性能事件时，对这些微指令进行标记。一旦被标记，微指令便将标签保持到成功引退，或被取消为止。如果微指令通过了引退逻辑单元，被标记的微指令将引发相应性能事件的计数，从而记录了猜测成功的事件。

         Pentium4实现了3种标签机制：前端，执行，与重演（replay）。前端标签机制标记那些处理流水线早期事件的微指令。流水线早期事件包括：指令预取、指令分类以及从追踪缓存（Trace Cache）中获取微指令等。执行标签机制负责标记几类特殊的指令，这些指令会把结果写回到寄存器文件中。重演标签机制负责标记那些重发射（Reissued）的微指令。通常，Cache失效、分支预测失败、违反依赖关系、资源冲突等都会引起微指令重发射。前端与重演标签机制在每个微指令中设置了一个有效标志位，因此一次仅能处理一个事件。而执行标签机制在每个微操作中设置了4个标志位，可以同时跟踪4个事件。可以通过几个面向机器的寄存器（MSR），以及ESCR中的标记（Tag）和标记值（Tag Value）位段来使能这些标签机制（如图3所示）。

基于事件的精确采样（PEBS：Precise Event-based Sampling）

         Pentium4对PEBS的支持是性能监测的显著进步。之前的处理器仅支持IEBS（Imprecise Event-based Sampling），不精确的分析有时是毫无用处的。

         为了支持PEBS，Pentium4改进了采样数据的收集方法。之前的处理器只不过在性能事件计数器溢出后，触发一个宏指令中断（Macroinstruction Interrupt），然后由ISR收集相关的采样数据。而深度流水、超标量执行以及从计数器溢出到中断产生之间的延迟都使得采样的精确性存在较大的变数。Pentium4使用了一个微助理（Microassist）和一个微代码助理（Microcode-assist）服务例程来为PEBS捕获采样数据。微助理（处理器内部在执行微指令时的中断）变换微指令执行流的方式类似于中断变换指令执行流的方式。微助理在指令执行期间处理那些不常见的问题（如在发生除0错误时，引发一个异常）。在微助理发出信号后，某个微代码助理服务例程将处理由该微助理引发的问题。使用微助理与微代码服务例程为PEBS收集采样数据，能够避免IEBS中的导致不精确的因素。

实现

         Pentium4中，PEBS的工作方式如下。首先，用户需要在内存中分配一块空间以保存收集到的采样数据，然后在PEBS_ENABLE MSR（Machine-Specific Register）中设置一位，使能PEBS。随后，用户需要配置一个微指令标签机制，用以标记通过流水线的特殊微指令。用户还需要配置一个计数器用以统计被标记的微指令中，引退者的数量。一旦计数器溢出，Pentium4的引退逻辑将审查所有的引退微指令。如果发现被标记的引退微指令，引退逻辑便在被标记的微指令引退之前触发一个微助理。微助理类似于一个宏指令中断，它会中止正常的指令执行。而与软件中断不同的是，处理器完全使用微代码来处理微助理，而且在微助理服务例程结束之前，那些位于引发微助理的指令之后的指令不会引退。微助理服务例程通过将当前的程序计数器与通用寄存器的值存储在预先分配的PEBS缓存中，来收集真实的采样数据（采样数据的收集完全由硬件完成，而不是之前的ISR。而且，采样数据的收集是在中止执行流的情况下完成的）。在完成微助理之后，处理器将恢复正常的执行。引起该事件的执行也将引退。

         用微助理与微代码助理服务例程来收集采样数据，而不是宏指令中断与ISR，避免了IEBS中所有导致误差的因素。因为微助理会在引发事件的指令引退之前被触发，因而可以确保与该指令相关的采样数据是精确的。在IEBS中，由于指令引退与收集采样数据的ISR被执行之间的延迟导致的采样数据不精确，在微助理的方式下，也不复存在。

         微助理在每次存储采样数据之后，都会检查PEBS缓存中的数据量。一旦该缓存中的数据量达到了高水位，便触发一个中断，随后执行的ISR将PEBS缓存中的数据拷贝到一个可以持久保存的位置。在清空缓存后，可以收集更多的采样数据。使用PEBS后，采样数据的收集不再由ISR负责，因而中断响应延迟也不再会影响采样的精确度。

缓存

         与IEBS相比，Pentium4的PEBS还具有另一个优势：缓存采样数据的开销非常低。因为PEBS在ISR的一次执行中，能处理多次采样。相比较而言，IEBS在每次采样时都要执行一个ISR。采样处理效率上的改进，能够降低对被监测系统的干扰。或者说，在干扰程度相同的情况下，可以收集更多的采样数据。

基准测试程序

         为了阐述PEBS相对于IEBS的优势，作者编写了一个简单的基准测试程序。该程序在一个嵌套循环中使用了Load指令，从而引起Pentium4中L1数据Cache的频繁失效。虽然每次循环中仅有一个Load指令会引起Cache失效，在该Cache失效被处理之后，随后大量的Load指令总是产生Cache命中。作者在Pentium4上分别使用PEBS和IEBS为L1数据Cache的失效情况创建了基于事件的分析。

         图5总结了该测试的采样结果。对于PEBS，能够百分之百地找到引起L1数据Cache失效的Load指令。如图5中“+0”列所示。作为对比，基于IEBS的采样全都无法辨别出正确的Load指令。而且，被IEBS辨别出的指令中，有65%或更多的指令在目标指令之后。（例如， 46.5%的采样辨别出的Load指令位于目标指令之后的69个Load指令中）。Pentium4中，IEBS的不精确程度比Pentium Pro处理器还要严重。ProfileMe团队之前对Pentium Pro处理器上的情况做过评价。这种严重的误差源自Pentium4激进的设计，以及处理器周期与访存时间的剪刀差进一步增大。当然，这也说明Pentium4更加有必要支持PEBS。

         基于Pentium4的PEBS，还可以进行数据地址分析（Data Access Profiles），而基于IEBS是不可能进行这种分析的。数据地址分析能够获取各种与存储系统性能事件相关的数据，以及这些数据在内存中的地址。Cache与TLB的失效就属于此类事件。用户可以再现引发性能事件的微指令所用的数据在内存中的地址。为了实现这个功能，需要对PEBS采到的指令进行解码，以得到指令操作数的有效地址。通过分析这些数据的内存地址，程序员能够找到制约存储系统性能的数据区域。一旦程序员找出了这些区域，便可以重新安排数据结构在内存中的布局，降低存储系统性能问题发生的频率。在之前的处理器中，是无法基于IEBS进行这种分析的，因为IEBS在辨别引发存储系统性能事件的指令时，经常出错。

图5. PEBS与IEBS下，采样精度的比较

         我们使用上面的基准测试程序来说明如何创建和使用数据地址分析。首先，需要为li_miss程序创建一个地址分析，此时可使用重演标签机制，以标记引起L1 Cache失效的Load微操作。作者还配置了一个计数器用来统计引退的加标签微指令的数量。该测试程序产生了8千万次L1 Cache失效。在使能了PEBS之后，进行了第二次测试。每发生10万次L1 Cache失效，进行一次采样，共获得了800个采样数据。正如前面提到的，所有的800次采样都正确地辨别出了引起L1 Cache失效的指令。该指令的地址、微操作与操作数如下所示：

80484c3: mov (%EAX), %EAX

该Load指令将EAX寄存器的值作为加载数据的内存地址，并将相应的数据写入EAX寄存器中。在采样时，EAX寄存器中保存的地址就是引起大量L1 Cache失效的内存地址。表1给出了每次采样时，EAX的值。该表中，“sample count”列表示所有的采样数据中，具有相同的EAX值的数量。这些采样对应的扩展指令指针，具有相同的值（0x80484c3），参考前面给出的指令。第二列是相应的EAX的值，即引起L1 Cache失效的Load指令所使用的内存地址。该列根据EAX的值，从小到大排列。

         通过分析Table1中的内存地址数据，我们可以推出l1_miss测试程序的行为。第一，注意每个EAX值的低12位都是相同的。第二，相邻2个EAX值的差为8KB。这正好是Pentium4的L1 Cache的容量。Pentium4上的L1 Cache为4路组相联的。测试程序对这8个相距8KB的内存位置循环地访问，造成了L1 Cache的颠簸（Thrash），L1 Cache仅能同时保持对这组地址4次访问的内容。分析结果符合测试程序的行为，测试程序中，具有8次迭代的循环（8-interation loop）每次都跨越一个大小为8K的数组，而该测试程序每执行1百万次循环，便引发一次Cache失效。如果这是对某个真实应用程序的分析，我们便可以使用分析结果来降低频繁的Cache失效。比如重新排列访问这些数据结构的指令，或重新安排数据结构在内存中的布局。

问题、局限和机遇

         虽然与其父辈相比，Pentium4的性能监测得到了显著地改善，但它当前的实现仍具有一些问题和局限。这些问题中，最显著的有相关文档的匮乏，实现时存在Bug，以及某些特性尚未公开等等。Pentium4微体系结构在复杂性上的陡然增加，使得清晰明确地描述其性能监测事件变得异常困难。本文档的早期版本曾秘密地描述了一些事件，但仍然省略了很多关键信息。比如，在对前端标签机制的早期描述中，没有列出任何前端标记机制能侦测到的事件。

         不过，Intel一直在网上更新此文档，每个版本都有显著地进步。最新的版本（包括对Xeon处理器的Hyperthreading功能的描述）补充了最初版本中省略的若干内容，并开始尝试规范性能监测事件及其特性的含义与使用方法。

         性能监测单元中存在的Bug，使得某些功能很难被利用。比如，用于侦测IOQ_allocation事件的逻辑方程在不同版本中具有不同的定义，而且在统计该事件时无法区分用户模式和特权模式。如果Intel的设计人员解决了这些问题，本文档也会相应地更新。

         最后，几种性能监测功能尚未被写入文档。比如，Intel仅在文档中描述了一种前端标签事件：μop_type。很多功能之所以没有公开，是因为Intel的设计人员在对外发布处理器时，还没有对这些功能进行充分地验证。虽然性能监测很重要而且很有用，但它并不会影响处理器的销量。因此，相比较其它更重要的处理器功能而言，公司在实现、验证与维护性能监测单元上投入的资金非常有限。比起处理器的正确性与整体性能而言，性能监测似乎不是很重要。

         随着对称多处理与超线程越来越常见，性能监测的需求也越来越大。在性能监测单元上，有3个方面急待改善。

         首先，利用线程ID区分事件侦测与利用线程模式区分事件计数的接口与机制，很难扩展到具有2个以上的线程的情况。如果未来的处理器增加了超线程的级别，就可能需要不同的方法来提供此类能力了。

         第二，当前性能监测不支持面向特殊任务的事件计数。在分时操作系统上，性能计数器统计的是当前处理器上执行的所有任务的情况。当多个任务共享处理器时，在不更改操作系统的前提下，我们不可能为每个任务单独计数。在处理器缓存PEBS的采样数据时，同样存在这个问题。在当前的Pentium4处理器上，如果操作系统在PEBS的ISR清空PEBS缓存之前切换任务，那么缓存中将包含多个任务的采样数据，而我们也无法辨别这些数据对应着哪个任务。

         第三，性能监测单元所支持的事件，以及选择事件与配置各种性能监测机制的软件接口在每一个微体系结构（Microarchitecture）上都是不同的。比如，在Intel的技术中，当前最常见的微体系结构有3种，而这3种微体系结构支持的性能事件各有不同。

l  P5微结构，最初应用在最原始的Pentium上，并最终演化成了Pentium MMX。

l  P6微结构，最初出现在Pentium Pro上，并最终演化成了Pentium II与Pentium III处理器，以及相应的Celeron与Xeon版本。

l  Willamette微结构，最初的Pentium4就使用的这种结构，并最终演化成了超线程的Pentium4 Xeon。

很多性能事件都是面向微结构的，事件的定义与接口的改变使得相应软件的开发与维护非常困难。有一些软件工具可以解决这些问题，比如Intel的Vtune（http://developer.intel.com/

software/products/vtune/vtune60/index.htm）以及PAPI（http://icl.cs.utk.edu/projects/papi/）。无论如何，最好还是能设计出一组可以适用于各种微结构的性能事件集合。

Intel的Pentium4处理器提供的性能监测功能，克服了先前处理器上性能监测硬件的诸多局限。Pentium4提供的新特性大幅增强了精确采集处理器性能数据的能力，使得一些新的性能调节工具得以开发出来，比如对应用程序与操作系统的动态调节。

 

参考文献

   [1]     D. Marr et al., “Hyper-Threading Technology Architecture and Microarchitecture,” Intel Technology J., vol. 6, no. 1, 14 Feb. 2002, pp. 1-12; http://developer.intel.com/technology/itj/2002/volume06issue01/art01_hyper/vol6iss1_art01.pdf.

   [2]     J. Dean et al., “ProfileMe: Hardware Support for Instruction-Level Profiling on Out-of-Order Processors,” Proc. 30th Symp.Microarchitecture (Micro-30), IEEE CS Press,Los Alamitos, Calif., 1997, pp. 292-302.

   [3]     IA-32 Intel Architecture Software Developer’s Manual Volume 3: System Programming Guide, order no. 245472, Intel, Santa Clara, Calif., 2002; http://developer.intel.com/design/pentium4/manuals/.