在Intel(R) Core(TM) i7 处理器上的Intel(R) VTune(TM) Performance Analyzer 的性能计数器

转自http://software.intel.com/zh-cn/blogs/2009/03/18/intelr-coretm-i7-intelr-vtunetm-performance-analyzer/

 

以前在CDSN的多核软件开发论坛上发表过有关Intel(R) Core(TM) 2 Duo 的性能计数器的论述(http://topic.csdn.net/u/20080527/17/44d9ebf9-959d-4495-8456-62e4b2d40f05.html),现在就Core(TM) i7 处理器的同样话题作一梳理。

 

VTune(TM) Performance Analyzer不仅可以检测程序所耗用的时间，而且可以检测程序执行中处理器的内部事件(Performance Monitor Unit : PMU)发生次数(及样本),称之为Event based sampling (EBS)

 

有关直接性能数据的计数器：

1)       CPU_CLK_UNHALTED.THREAD - 表示非停机状态花费的机器周期

2)       INST_RETIRED.ANY - 表示指令的有效执行的计数

 

CPI = CPU_CLK_UNHALTED.CORE / INST_RETIRE.ANY, 表示一段代码（函数，模块）平均每条指令花费的机器周期．自然是愈小愈好. 
这样你就可以找到那些CPU_CLK_UNHALTED.CORE大的函数，且CPI也大的函数，去关注(通常称之为热点函数)

 

CPI的值，理论上可以达到0.25 (但事实上不可能,只是愈接近愈好)。

 

当你得到一个不太满意的CPI 的值时候，就要探知它的道理。

CPU_CLK_UNHATLED.THREAD = Real_Work + Resource_Stalls + Rat_Stalls + Seg_Rename_Stalls – Uops

 

Real_Work 一般指的是你需要相应的指令序列来实现你的算法。考量你的指令是否最精减。

Rat_Stalls 指的是Register Allocation Stall, 此时没有寄存器可用，需等待。

Seg_Rename_Stalls 指的是段寄存器的重名不可用，需等待。

 

我们考虑得最多的应是Resource_Stalls, Uops. 先谈 Resource_Stalls, 包含：

RESOURCE_STALLS.LOAD – 由于Load Buffer 不可用以致延时

RESOURCE_STALLS.RS_FULL – 由于Reservation Station满，新指令不能进入以致延时

RESOURCE_STALLS.STORE -  由于Store Buffer 不可用以致延时

RESOURCE_STALL.ROB_FULL – 由于Re-order buffer 满以致延时

RESOURCE_STALL.FPCW – 由于浮点控制字不可写（被占用）以致延时

RESOURCE_STALL.MXCSR – MMX 状态控制寄存器重名失败以致延时

 

RESOURCE_STALL.OTHER – 包含了以前我们知道的：(下面举例)

BR_MISP_EXEC: 分支预测失败

ILD_STALL: 指令长度解码延迟

L2_LINES_IN: L2 缓存没有命中

ITLB_MISSES

DTLB_MISSES

 

Uops – 包含micro-ops retired, macro-ops retired. 当然是多多益善。使用UOPS_RETIRED 可以知道微操作和宏指令的熔合数。建议多用简单指令，少用复杂指令。

 

其他：SNOOP_RESPONSE, 当一个内存的数据在一个核的L1缓存，而另一个核也要访问这个数据。这会引起缓存的状态改变，如频繁这样操作，会引起性能下降。

 

这里还有一些常规的话题，如：总线，浮点，SEE 等，就不在这里一一展开了。