这一切都可使用工具本身的Suppression功能来完成。

情形1. 假设用户是测试人员，每次只要关心有无新的报错。

步骤1. 检查内存错误或线程错误，结果放在指定目录， 如

inspxe-cl –collect mi2 –result-dir myRes -- ./tachyon_find_and_fix_memory_errors dat/simlpeball.dat

步骤2. 将结果产生于.sup 文件， 如

inspxe-cl –create-suppression-file default.sup –result-dir myRes

步骤3. 再次测试，过滤掉上次的已知结果， 如

inspxe-cl –collect mi2 –suppression-file default.sup –result-dir myRes1 -- ./tachyon_find_and_fix_memory_errors dat/simlpeball.dat

*.sup 文件不可以手工编辑，如用户想要有选择的选取“过滤”内容，可以把.sup文件加入Inspector XE的Project Properties – 在图形界面上取舍内容。本文最后有描述。

情形2. 有些报错内容来自第三方的软件，或暂时不关心的库文件

请参阅此文 - http://software.intel.com/zh-cn/blogs/2011/08/08/include/

“include”模式：报告的错误，来自指定的模块。

“exclude”模式：报告所有的错误，除了列出的模块。

上文中，例子中使用的是命令行的方式，用户也可以在图形界面上设定。

情形3.分析前次结果，去掉“不合理”的报告项。以后运行Inspector XE再也不会出现这些项。

步骤1.运行完整的检查，浏览报告，找出“不合理”的项，按右键，选“Suppress…”

VTune™ Amplifier XE 性能分析工具可以使用处理器的性能计数器采集样本，进而对事件（如缓存不中，分支误测，写缓冲满等）高频发生的代码进行优化，以提高程序的整体性能。

 可是当我们使用事件OFFCORE_RESPONSE.ANY_REQUEST.LLC_MISS_LOCAL.DRAM_0 和 OFFCORE_RESPONSE.ANY_REQUEST.LLC_MISS_LOCAL.DRAM_1 希望得到第三层缓存不中的情况，

amplxe-cl -collect-with runsa -knob event-config=OFFCORE_RESPONSE.ANY_REQUEST.LLC_MISS_LOCAL.DRAM_0,OFFCORE_RESPONSE.ANY_REQUEST.LLC_MISS_LOCAL.DRAM_1  -- multiply.exe

得到的结果却是：

其实OFFCORE_这一类事件并不是基于每个内核的，所以VTune并不会做Event Based Sampling (EBS), 而仅做 Event Based Counting (EBC)。也就是说只记不采（样）。 

而想要知道层三的缓存不中的情况，要使用

amplxe-cl -collect-with runsa -knob event-config=MEM_LOAD_UOPS_MISC_RETIRED.LLC_MISS_PS -- multiply.exe

得到希望的结果：

那么，可能有同学要问，既然使用这些“只记不采”的Uncore事件得不到结果，为什么要放在事件列表中？

其实还是有用的。比如工具中有一种预定义的分析类型叫“Bandwidth”，是分析内存访问带宽的，就用到OFFCORE_的事件。

CPU_CLK_UNHALTED.THREAD 记录Core Cycles， 当你的线程处于非待机状态。我们知道，由于Intel (R) Step Speed 技术，核的频率可能由于CPU的“忙”或“不忙”随时发生变化。如果核上一直很忙（密集型计算）那么核的频率是个常量，这样程序的执行时间（Elapsed Time）可以计算出来：Elpased_Time = CPU_CLK_UNHALTED.THREAD / CPU_frequency (Seconds)

CPU_CLK_UHHANLTED.REF_TSC 也是用于线程处于非待机状态下记录clocks。所不同的是这个事件计数器不会受到核的频率改变的影响。大家可能还记得有条指令叫RDTSC。TSC是通过震荡电路分频产生的，供操作系统使用（作为定时器，频率稍低于主频，但不受主频的变频影响）。这个事件也可以用来计算程序的执行时间，事件数（clocks）除以TSC的频率（TSC的频率查阅手册）

CPU_CLK_UNHALTED.REF_XCLK 是一种超低频的时钟，也是由震荡电路分频产生。当系统不是处于待机状态，100Mhz的低频时钟用于维护CPU核心，内存，Uncore和外围电路上。100Mhz（3000MHz (30x 100MHz)）的固定频率比Nehalem架构的133Mhz更省电。

有二点说明：

1. 性能调试时，尽量不使用Intel® Turbo Boost超频技术，否则性能计数器的结果较为复杂，难以解释。

2. 性能调试时，尽量不使用Intel® Hyper-Threading 技术，因为有些性能事件是基于每个线程，有些是基于每个核的。

总结一下：当使用VTune™ Amplifier XE进行CPU耗时测量（热点分析）时，如果目标应用程序是密集型计算（期间主频不变），选择CPU_CLK_UNHALTED.THREAD；否则应该选用CPU_CLK_UHHANLTED.REF_TSC计时。

Intel® VTune™ Amplifier XE 改善了Call Graph的性能问题，采用统计调用（Statistical Call Graph）的方法，把Sampling（采样）和Call Graph（调用图）的功能（过程）合二位一。这种方法不仅帮助用户找到热点函数，而且找到了调用者的函数以及热点函数调用者的贡献度（消耗CPU的时间，对热点函数而言）。

美中不足的是，虽然基于统计的样本收集（Statistical Sampling）给出了热点函数以及调用关系，但是没有给出调用次数（call count）。

而另外一个实验工具Intel® Performance Tuning Utility (PTU)  却能很好的解决这个问题。

下载后，解开这个工具包，无需安装。运行此工具会检查许可证（license）, VTune™ Amplifier XE的license可以和PTU共用。本文我们不使用PTU中的Event Based Sampling，就无需卸载VTune™ Amplifier XE的驱动程序以及安装PTU的驱动程序（如有此需求，具体方法见这篇文章）。

直接在解压缩目录下打开Eclipse，如 /home/peter/ptu40_003_lin_intel64/eclipse/eclipse

创建一个PTU project, 关联一个目标应用程序，然后按右键选“Profile as” – “Basic Call Count”, 运行后产生报告。此报告含应用程序运行中调用到的所有模块（包含了系统的库函数和用户的库函数），可以按程序名和调用的次数进行排序。一般而言，我们可以按感兴趣的模块过滤结果。

此结果最大的用处是：基于VTune™ Amplifier XE 的热点报告，知道热点函数的时间和每个调用者的“贡献度”，可以知道函数一共被调次数和每个调用者的调用次数（假设PTU和VTune™ Amplifier 测试时目标程序的执行路径是一致的）。

尤为重要的是，我们要找”最热”的函数中“call count”值最大的。此种函数性能上稍作改进，由于调用次数多，对整个应用程序性能的提高，可以“立竿见影”。

1. User-mode Sampling and Tracing Analysis：

热点分析(Hotspots Analysis)，并行分析(Concurrency Analysis)，锁和等待分析(Locks and Waits Analysis)

2. Hardware event-based sampling analysis

一般性研究（General Exploration），内存带宽（Bandwidth），访问冲突（Access Contention），分支预测（Branch Analysis），存储访问（Memory Access），端口饱和（Port Saturation），等。

用户可以在amplxe-gui（图形界面）使用上述预定义的分析类型，结果产生在响应的报告。

当然用户也可以使用命令行（参阅此文）收集性能，结果也可以在命令行输出或导入工具的图形界面。使用命令行的好处是用户可以自定义自己的分析类型，如：

1. 热点分析中，自定义采样间隔，参阅此文
2. 自选的CPU事件计数器，参阅此文 

VTune™ Amplifier XE 定义了多种自己的输出格式，可以显示在工具的图形界面上。除此之外，工具还支持了gprof的输出格式。此种格式仅可以在命令行输出，不可以在图形界面上输出。

请看下面例子：

VTune的输出格式列出最热函数，而不是全部；gprof格式给出全部函数（即使占用CPU时间极少），且注重函数间调用关系

# amplxe-cl -collect-with runss -knob interval=8 -knob collectSamplesMode=stack -- ./primes.icc
Determining primes from 1 - 100000
Found 9592 primes
Using result path `/home/peter/problem_report/r000runss'
Executing actions 75 % Generating a report
Summary
-------

Elapsed Time:  0.883
CPU Time:      2.080
Executing actions 100 % done               

# amplxe-cl -report hotspots
Using result path `/home/peter/problem_report/r000runss'
Executing actions 75 % Generating a report
Function    Module      CPU Time
----------  ----------  --------
findPrimes  primes.icc  2.080
Executing actions 100 % done                                                   

# amplxe-cl -report gprof-cc
Using result path `/home/peter/problem_report/r000runss'
Executing actions 75 % Generating a report
Index  % CPU Time:Total  CPU Time:Self  Children  Name           Index
-----  ----------------  -------------  --------  -------------  -----
[0]    100.0             0.0            2.08      clone          [0]
                         0              2.080      start_thread  [1]

                         0              2.080      clone         [0]
[1]    100.0             0.0            2.08      start_thread   [1]
                         2.080          2.080      findPrimes    [2]

                         2.080          2.080      start_thread  [1]
[2]    100.0             2.08           0.0       findPrimes     [2]

[3]    0.0               0.0            0.0       _start         [3]
                         0              0          main          [4]

                         0              0          _start        [3]
[4]    0.0               0.0            0.0       main           [4]

Index by function name

Index  Function
-----  ------------
[3]    _start
[0]    clone
[2]    findPrimes
[4]    main
[1]    start_thread
Executing actions 100 % done

使用amplxe-gui，调用工具的图形界面，创建一个项目，选择目标的应用程序。然后通过工具对目标程序进行热点分析（Hotspots Analysis）, 意外得到出错信息。

同样的问题也会发生在并行性分析（Concurrency Analysis）和锁及等待分析(Locks And Waits Analysis)。

究其原因，Ubuntu* 10.10以后的版本对于一个普通用户在使用ptrace追踪进程时，仅允许被追踪进程的父进程ptrace 应用程序的进程。

而VTune Amplifier XE并非应用程序的父进程。怎么去除这个限制呢？根据出错信息的提示：

$sudo echo 0 > /proc/sys/kernel/yama/ptrace_scope

bash: /proc/sys/kernel/yama/ptrace_scope: Permission denied

应该使用：

$echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

[sudo] password for peter:

0

这样, VTune(TM) Amplifier XE 就可以正常工作了。

这是一篇受密码保护的文章。您需要提供访问密码：

密码：

Intel® VTune™ Amplifier XE主要包含二种类型的性能数据收集：一种是用户模式下的数据收集和追踪分析, 还有一种就是基于硬件PMU事件的采样 （EBS）。

本文仅讨论的第一种情形（热点分析，并行分析，锁和等待分析），并不需要管理员权限（administrator privilege），缺省使用的是OS timer作为中断源。如 CPU Sampling Interval 10ms 作为预制的delta。但是其本质是粗略的，难以精确到 晶振的ticks。另外的问题是，由于中断源的级别较低，中断也可能被其他的中断屏蔽，影响到精度。

最近的产品更新，针对以上的“瑕疵”，缺省使用新的中断源-访问Event Tracing for Windows (ETW)。 ETW是一种内核级别的编程接口，追踪内核/程序的性能和提供Log文件。

即使你的用户账户具有管理员权限，在使用工具过程中 都必须以“Run as administrator”启动 以下方式之一 ：1）devenv (Viusal Studio 的集成环境) 2）amplxe-gui  3) cmd (命令行) 。否则的话，就会出现以下警告信息，并且数据收集是使用OS Timer作为中断源的（不过结果还是可用的）。

1.  什么是Uncore 事件?

遗憾的是，早期的版本不支持在报告中输出热点函数的调用栈信息。现在VTune(TM) Amplifier XE Update 5 命令行的报告增加了此选项。

amplxe-cl -rept-list
Executing actions  0 % Gathering available reports
vailable reports:
callstacks                                        predefined
gprof-cc                                          predefined
hotspots                                          predefined
hw-events                                         predefined
perf-detail                                       predefined
perf                                              predefined
pmu-events                                        predefined
sfdump                                            predefined
summary                                           predefined
top-down                                          predefined
wait-time                                         predefined   

由此用户不仅可以输出热点函数的信息，还可以输出热点函数调用者的信息。

amplxe-cl -report callstacks -r r000hs |more
Using result path `C:\zwang\Demos\tachyon\vc8\find_hotspots_Win32_Debug\r000hs'
Executing actions 75 % Generating a report
Function                      Call Stack                   Module             CPU Time:Self  CPU Time:Total
----------------------------  ---------------------------  -----------------  -------------  --------------
render_one_pixel                                           find_hotspots.exe  0.078          96.11%
                              draw_trace                   find_hotspots.exe  0.078          96.11%
                              thread_trace                 find_hotspots.exe

                              trace_shm                    find_hotspots.exe

                              trace_region                 find_hotspots.exe

注意：此功能只对User-mode Sampling的分析类型有效。而Hardware Event-based sampling是不产生调用栈信息的。