如何着手使用VTune™ Amplifier XE针对你的项目进行性能调优,以及进行常规化自动测试

介绍最新的VTune™ Amplifier XE的文章写了不少,虽然新的产品集成的VTune™ Performance Analyzer和Intel Thread Profiler的大部分功能,可能用户还是难以针对自己的项目找到突破口。

记得以前写过一篇名为<12步法-用英特尔的性能工具诊断性能问题>, 可能对大家有些帮助。觉得有必要针对新的产品,重新写一篇简单指导,顺便把以前有用的文章“串联”进本文。

还是论述下三个层次上的调优。

系统调优:和VTune™ Amplifier XE 有关系,但关系不大。系统调优主要是改变硬件配置,如:网络bandwidth,磁盘Read/Write per second,内存 Page Fault,等。说它和产品有关系,如(使用LocksAndWaits Analysis测出)过长Network Socket Object的等待时间,过慢Disk Write I/O 可能引起线程阻塞。通过重新的系统配置加以改进。又如,使用Memory Access Analysis测出缓存的不中率过高(资源配置过低)而通过系统升级的方法改进。凡此种种,和编程的关系不大。

算法调优:指通过算法的改写或实现方法的改变,达到程序性能的提升。

一种情况,全部或大部分串行代码,需要通过热点分析找到热点函数,有条件的话进行并行化(可以手工增加线程任务;可以使用编译器自动并行化;可以使用TBB,Cilk Plus,等)。当然也可以通过调用关系调整算法,如发现重复计算,减少函数调用次数。

另外一种情况,程序已经并行化,需要通过并行性分析得知程序整体的并行度。进而观察热点函数的并行度,如果热点函数并行度差(占CPU大部时间的函数所在的线程没有和其他线程并行),可能的原因是:1)任务在各线程的分配不均衡,可通过调节算法实现;2)线程的阻塞(Wait time)是由于共享资源或“锁”被其他线程占用。找出阻塞的原因一般使用LocksmithAndWaits Analysis。在这种情况下,需要考察占用的资源在其他线程上是否有必要长时占有共享资源。如:把敏感区域尽可能缩小;减少数据的依赖关系,等。另外可以使用较“轻量”的锁。

 基于处理器微架构的调优:这种情况往往需要开发者具备处理器的知识,往往是开发者比较困扰的。而当热点函数被大量调用时,这又恰恰是比较有用的。

这方面的文章,以前写过不少。如:

关于Intel® VTune™ Performance Analyzer的性能计数器

在Intel® Core™ i7处理器上的Intel® VTune™ Performance Analyzer的性能计数器

读者还可参阅此文- Using Intel® VTune™ Performance Analyzer to Optimization Software on Intel® Core™ i7 Processors

这些文章的中心思想是:Execution Time = Real_Work + Penalties。一般使用VTune™ Amplifier XE 的lightweight-hotspots 找出热点函数,尤其关注CPI(Cycles per Instruction)高的函数(含浮点指令和SSE/AVX的指令除外),落实到相应代码行,观察可能引起的原因,使用相应性能计数器进行验证。优化代码再进行测试。

 需要指出的是,性能计数器种类繁多,而且不少有重叠(Overlap)。VTune™ Amplifier XE 预定义一些常用的,用户也可以自定义自己的分析类型(不过需要相应的处理器专业知识)。需要学习的读者可以参阅下文:

Cycle Accounting Analysis on Intel® Core™2 Processors

Performance Analysis and SW optimization for HPC on Intel® Core™ i7, Xeon™ 5500 and 5600 family Processors*

一般而言,在多核平台我们总是把并行(算法)调优作为首要任务,基于微架构调优次之。

 作为测试部门,用户经常使用产品的命令行(在测试脚本中)进行自动化测试,产生报告(归档),以进行代码性能监控。有关命令行的使用,可参阅“帮助”;也可阅读以下文章,以期快速上手。

使用amplxe-cl命令行进行性能数据收集和分析

VTune™ Amplifier XE: 命令行上直接使用用户分析参数,无需创建新的分析类型

 在测试过程中我们可以监控进程,线程,模块以及函数。以下是性能数据监控举例(amplxe-cl输出报告):

1.记录每次程序的Elapsed Time

2.程序的并行度<1.5, 不达标

3.CPI>1.8, 不达标

4.Execution Stall > 20% (什么模块?)

5.L2 或 LLC Miss > 20%

6.Branch Misprediction Percentage > 50%?

7.Front-end Stall (UOPS_ISSUED.CORE_STALL_CYCLES – RESOURCE_STALLS.ANY)

 凡此种种,不一而足。用户可以选择自己Events (或Event Ratios), 及Threshold 作为质量监控的目标。数据产生的报告可以是Summary,模块的,函数的。

For more complete information about compiler optimizations, see our Optimization Notice.