zoukankan      html  css  js  c++  java
  • Intel软件工具VTune使用说明

    0.     概述

    VTune Intel 一个比较强大的性能分析软件。主要包括三个小工具:

    1 Performance Analyzer : 性能分析,找到软件性能比较热的部分,一般也就是性能瓶颈的关键点,帮助我们收集数据发现问题,至于 Analyzer 这个功能,有点大言不惭了,还得靠各位大家自己分析了,当然 个人认为这一点会是 Intel 下一步强化该工具的重点。

    2 Intel Threading Checker 用于查找线程错误 , 能够检测资源竞争、线程死锁等问 题 . 大家程序在并行化后 , 可以通过 Threading Checker 检测一下有没有多线程相关的错误。

    3 Intel Threading Profiler :线程性能检测工具 , 多线程化有可能会有负载比平衡 , 同步开销过大等等线程相关的性能问题。该工具可以帮你发现每一 个线程每一时刻的状态。

    可以简 单认为该工具是如下的使用顺序:(发现可以多线程的代码瓶颈) --- 进行并行等编码阶段 --- (发现多线程中错误部分) --- 改正代码 bug 阶段 --- (发现多线程中有待提高的瓶颈部分) --- 优化代码性能阶段。可以看出这套软件针对代码并行的实现有点服 务到家的感觉,核心思想就是: 找茬

    另外推 荐一个配套的工具,就是 Intel C++ 编译器,可以集成到 VS2005 或者命令行下,配套使用应该会一些更好的效果,传说中对 Intel C++ 编译器好像都是赞不绝口的,而且都是自家的东西, Intel 肯定不会亏待它的。

    还有一 个网上推荐的东西,直接粘贴过来,没有了解过,不好多加评论 : Intel MKL 函数库,提供了 VML 函数 , 这些函数可以对超越函数 (sin, cos, exp, log ) 进行优化。

    此外友 情提示一下,如果你使用的是 AMD CPU 芯片,并一心决定以后继续使用它的话,建议同学你就不用往下看 了,理由就不告诉你了 ^_^

    本文章 主要是对 VTune 的一个初级使用的心得总结,有什么不对的大家多扔板砖,算是一个抛砖引玉的作用吧,欢迎大家一起总结完善!

    1.    Intel Performance Analyzer

    对于该 工具使用比较简单,不过直接说一下,软件名称是性能分析,实际上只是对软件操作进行时间上的总结和统计,用户自己需要根据数据进行分析,总体来说,该性能 分析工具同 IBM 的性能分析工具大致一样,个人认为还不如 IBM 的好用的,呵呵。

    基本操作 :

    1 )新建一个工程: File->new project ,一般选 Quick Performence Analysis Wizard 就可以了。

    2 )选择要测试的程序,在弹出的对话框中有 Application to Launch ,填入 Debug 文件下的 exe 程序就行了。

    3 Run Activity :按工具栏上的绿色三角按钮就行了 , 一般会自动运行程序,这时你执行 你想要的操作。本来还有些配置可以配的,不过比较麻烦,一般的分析就算了。

    4 )完了就会生成很多表,最麻烦的就是怎么看这些数据。左边有这些数据的一个树型列表,可以选择看哪个统计表,中 间就是相应的图表现实,图表下面还有一个 Legend 窗口,解释图表中的符号各是什么意思。

           

     

    上图为分析的主界面。对于分析图表的结果,看上去比较多,其实真正有用的就一个(个人看法),首先出现的就是一 个框架的分析结果,有一个柱状图来体现各种 dll 和进程的时间占用统计,当鼠标在每一个柱子上停留, ToolKit 会显示该进程的平均执行时间和 执行的次数,右侧 Summary 概述该进程下占用的比例等统计,下面的 legend 说明机器的配置和一些名次解释。

    选择进入相应的进程,则看到对应进程中各个函数的对应信息,在此不再详细说明。这时通过统计图可以发现程序性能 主要的花费部分,这时就要运用你对代码的了解和分析、经验发现性能提升的地方,也就是你的性能最应该和最显著提高,这时点击你关系的函数,如果你有该函数 的实现文件( cpp ),则可以结合 Source File 进行一些简单的分析,这里可以给你提供源代码和汇编码两种方式来进行体现,供大家 选择。在 Sampling Results 中提供该进程下各个函数的时间统计,定位到每一个执行函数上(通常就是消耗时钟时间最多的,即关键代码)。如 图所示:

     

     

    比如上面这个分析结果,该函数是对图片像素进行优化分类、分割处理、生成结果的功能,具有大量的数字运算和循 环,这也是我们最应该和最有效采用多线程等手段提升效率的部分。源码右边的列表中给出了一些指令的执行次数和执行时间。经过分析又可以定位一些比较重点改 进的指令。

    总结此工具,和 IBM 的性能分析工具作用大致相同(个人感觉还是推荐 IBM 的,其实都差不多,主要是先入 为主了,而且图形界面比较直观),该工具的 Call Graph 选项也和 IBM 那样支持图形分析,但是我在机子上运行会崩溃,不知道为什么。该工具只是将分析 的数据呈现给我们,而分析的过程还要依靠大家。另外,在源码上点击会出现一个窗口,显示该行执行的次数等一些分析结果,不过我这个版本该功能还是很弱的, 近似于没有用处,可能会在下面的版本有所提升。

    注意:

    1 )该软件支持 Linux 系统,如果分析的软件属于跨平台产品,可以根据各自情况查看是否有必要也同事在 Linux 下分析,个人认为我们的软件没 有太大必要,完全可以在 Windows 下分析,发现问题进行改进,此功能主要针对只运行在 Linux 平台下的软件的,所以没有进行 研究。

    2 )该软件支持远程模式,没有发现我们的软件是否有此功能的必 要性,没有进行过多研究,只是发现一个帖子知道如何远程,会在附录中添加上。

    3 )使用 VTune GUI 去收集数据 可能 VTune 本身开销会影响分析结果,所以 VTune 提供命令行的分析模式,基本语法在附件中,个人认为现在我们 在图形界面下进行分析也会有很大收获,考虑到时间成本也没有进行过多研究。

    2.Intel Thread Checker

    非常不 错的一个工具,如果你用过上面性能分析的工具,这个上手也是比较容易的,界面和使用风格上保持一致,简单说这个工具也是对加锁解锁的数据收集和对死锁的检 测,将程序运行中发生的所有逻辑关系(读写操作)和认为死锁现象(时间过长)体现给程序员,让大家进行分析这些可能会导致 deadlock data races 等问 题。

    基本操 作:

    1 New Project ,在 New Project 对话框中,在 Category 下 拉框里选择 Threading Wizards ,在下面的 List View 中选择 Intel? Thread Checker Wizard ,然后 OK

    2 选择你想要检测的 程序,一定是 Debug 的,可以查看源代码,这个应该不是什么要求。

    3 Run Activity :按工具栏上的绿色三角按钮就行了 , 一般会自动运行程序,这时你执行你想要的操作。另外,对于死锁 问题,可以设定时间,在 Configure---Options---Cpllector--- Synchronization 中进行设定,来定义你认为作为死锁的最小时间设定。

    4 运行结束后生成很 多表,然后就是我们自己分析了。

    下面就 简要说明一下这些表的作用和一些个人的使用心得:

     

    上图是 运行程序后生成的主界面( Diagnostics ),以及源码界面( Source View ),这里最有用的信息主要是 Short Descption Descption 这两个列表内容,第一个表主要是对该操作可能导致的并行问题 的归类,比如 data race deadlock 等,如果对此类错误不是很理解,可以点击右键在菜单中查看 Diagnostics Help ,会对此 类型错误进行一个概括的介绍,如下图所示(介绍读写资源竞争):

     

    如上是 我在多线程程序中的一个数据竞争的现象的帮助文档说明,其逻辑关系是 Read 该数据后 Write 该数据,这种情况则可能会导致 Data Race 的问题, 这在点上, Thread Checker 则会把程序运行中的各种出现的逻辑情况都罗列并定位到代码所在 行。

    上图是 我在程序中的一个死锁问题的帮助文档的说明,给出可能的死锁原因,正是我在程序中用到了 WaitForSingleObject() 函数,导致了线程函数和进程条死锁的产生。同时可以定位到死 锁线程的源代码,这时候,就需要我们仔细研究死锁的原因了。下图是我查看死锁详细描述定位到源代码的界面(可见高亮显示的两个部分正是导致我线程死锁的原 因:创建后等待该线程,而此时线程调用 MFC 进程条,而进程条又在等该线程):

     

     

     

     

    对于 Descption 中的内容,则会阐述这个问题的具体内容,可以定位到具体代码 行,双击可以切换到代码,这时大家可以分析这行代码了,所示重点怀疑对象了,当然案件的真相和真凶则需要各位“侦探”来判断啦。

    以上是 我对 Data race deadlock 的两个问题程序进行的简单的分析报告,根据 Intel 对该工具的介绍和相关资料,该工具主要就是针对这两种情况进 行分析。一般并行运算主要就是这两种问题啦。(看资料应该可以做出这个判断)

    总体来 说该工具最有用的就是如上的两个表的数据分析啦,当然还有另外两个表,一个是 Stack Traces ,这个主要是对堆栈跟踪,可以发现该程序堆栈,看一下一共创 建了多少个线程之类的信息。另外一个则是图表统计,统计检测到的问题的一个堆叠柱状图。感觉用处不大。下图是堆栈跟踪图:

    3.Intel Thread Profile

    正如 Intel flash 演示中介绍的那样,这款工具的作用就是: improved thread application performance. 当然坦白的说,要想让工具自动实现这点不像说的那么简单,准确来说,它的作用应该是帮助我们提高线程 应用的性能,重点在“帮助”上。相对以上两个工具的作用和定位,感觉这款工具目前的功能和它自身的定位还是有一些差距的,没有很多像上面两个工具提供一些 分析的作用,而只是对代码多线程的一个统计和图形的直观显示,毕竟,要想让工具自己找到优化方案是有点强人所难的。还有感觉网上对这款工具的使用介绍也不 是很多,几乎没有,感觉不想上面两款软件应用的广泛或者大家的代码还没有达到这一阶段的要求吧。操作方法还是保持的一致风格,不用培训,直接上手。

    基本操 作:

    1 选择你想要优化的 程序, Debug 版本可以调试到源代码。在这点上程序支持普通模式(支持 Windows API 等)和 OpenMP 专有两个模式。这里选择第一个了,第二个不会用啊。

    2 Configure 中可以配置一些选项,查看该优化程序的 Dependence 等,推荐还是默认吧,个人认为足够我们用的了。

    3 点击 Finish 运行你的程序,运行你的多线程程序吧,然后在运行你需要检测 的程序功能后点击结束。        

    4 这时候则会生成一 系列表格图形让大家分析。

             下面我来简单介绍一下主要表的功能吧,都是一些很基本的方法, 刚刚上手,这个工具的使用教程网上不多,还没有研究很深入,需要以后在多线程开发中学以致用才是关键。

         TimeLine 表:顾名思义就是时间线的统计,如下表所示,在这个表中,统计了所有线程按照时间轴的状态:

     

     

     

             上图所示,在这个程序中,我创建了三个显示,在加上主线程,一 共四个,在这个时间轴中显示了这四个线程从生到死的每一个瞬间,对于这些颜色,在右侧会有说明,比较重要的比如绿色代表活动状态,浅绿代表等待。橙色代表 至少一个线程运行,灰色表示没有此时没有线程在运行。这样大家可以很清楚的看到每一个线程的全部状态,算是得到了程序线程运行的最直接、最表面的第一手资 料了。当然秉承的 VTune 的一惯风格,双击可以跟踪到源代码哦(如果你有的话)。

             Profile Filter 表:对线程各种状态的一个归类,对此还不是很熟悉,是对时间表 的各种状态的一个统计直方图,如下表所示:

     

     

     

             上图是对刚才那个时间表中各种线程各种状态花费时间一个统计图 对比,灰色的是非活跃阶段,橙色则是有一个线程活动的时间,统计出各个状态的一个百分比。可以看出上面有许多不同的显示方式,没有太多研究,应该是按照不 同的分类方式来对下面时间表的一个体现,大家可以按照自己的爱好去选择吧。

             另外还有一个 Summary 表格,是对整个程序运行的一个统计,在这个表格中数据要比图 表详细很多,毕竟图表只是一个通过图形将一个重点数据更加直观的表现,信息量相对数据来说要小很多,在这个摘要中,创建线程数,状态都统计成表格,图像如 下:

     

     

     

             总体来说,我对这个工具研究的时间不是很多,也不是很了解,只 是入门了,以后用到的时候在发挥啦,呵呵。这款软件就是将各个线程状态进行一个统计和时间表现给大家,大家可以发现在某一时间多线程性能可能会有不尽如意 的地方或还有很多提升空间,这样大家可以抓住本质,重点来最有效的优化我们的并行程序。

    ★emouse 思·睿博客文章★ 原创文章转载请注明:http://emouse.cnblogs.com
  • 相关阅读:
    x64 平台开发 Mapxtreme 编译错误
    hdu 4305 Lightning
    Ural 1627 Join(生成树计数)
    poj 2104 Kth Number(可持久化线段树)
    ural 1651 Shortest Subchain
    hdu 4351 Digital root
    hdu 3221 Bruteforce Algorithm
    poj 2892 Tunnel Warfare (Splay Tree instead of Segment Tree)
    hdu 4031 Attack(BIT)
    LightOJ 1277 Looking for a Subsequence
  • 原文地址:https://www.cnblogs.com/emouse/p/2198228.html
Copyright © 2011-2022 走看看