如何使用gprof对软件做profiling （一）

如何使用gprof对软件做profiling（一）一．XilinxZynq-7000带来新的设计思路在以前，我们的单板上往往有CPU和多片FPGA，由CPU完成系统的配置和管理，FPGA完成特定算法的硬件加速，受限于CPU和FPGA之间的通信带宽和延迟，CPU和FPGA之间的接口大多是用于配置和管理，无法传输大量的数据。Xilinx推出的Zynq-7000系列芯片很好的解决了这一问题。它内含硬化好的CPU核和常见的外设（DRAM控制器，千兆以太网，USB2.0OTG，SDcard控制器，FLASH控制器，UART，CAN，SPI，I2C等等），这一部分被称为ProcessingSystem（简称PS），它可以完全独立于FPGA运行；Zynq-7000芯片内部还有容量不等的FPGA资源，被称为ProgrammableLogic（简称PL），可以支持不同复杂度的逻辑设计。最重要的是，在PS和PL之间，有超过3000根的互联信号，包括9路AXI通道，可以提供大约100Gb/s的通信带宽，同时在PS和PL之间还有DMA，Interrupt和EMIO等多种资源。这就使得数据可以在PS和PL之间灵活高效的迁移，从系统设计的角度上来讲，任务可以在软件和硬件之间灵活的分割，实现高度优化的系统设计。这也给嵌入式系统的开发方法提供了新的思路和流程：首先利用软件可以快速灵活编程的特点，快速的用软件实现系统的原型；然后通过对软件进行profiling找出对系统性能影响最大的代码，将这部分代码用FPGA来硬件加速，实现高度优化的嵌入式系统；Xilinx还提供了HLS（HighLevelSynthesis）工具可以方便快速的把软件代码转化成RTL代码，帮助开发者快速的实现基于FPGA的硬件加速器。在这一流程中，重要的一环是如何找出软件中对性能影响最大的那部分代码。对于简单的应用，我们可以很容易的判断出来，例如对频谱分析来说，FFT算法就是最至关重要的需要优化的算法。但是在很多时候，软件非常复杂，有很多的复杂的函数调用，很难通过静态的观察和分析找出对性能影响最大的那部分代码，这时就需要通过profiling工具，在软件动态运行中收集数据，通过统计的方法找出核心代码了。二．Profiling的对象在Linux下有很多profiling工具，各自有自己的优势和劣势。在这里我们重点研究一下如何使用gprof对软件做profiling。很多介绍profiling工具的文章都是开发者自己写一个简单源文件，里面有简单的函数调用。

为了更好的展示profiling的效果，这里我们没有采用这种方法，而是采用了一个相对比较复杂的软件包libjpeg。libjpeg是一个完全用C语言编写的库，包含了被广泛使用的JPEG解码、JPEG编码和其他的JPEG功能的实现。这个库由独立JPEG工作组维护。编译完成后除了相应的.a和.so库文件之外，还会生成以下工具程序：

cjpeg和djpeg：用于JPEG的压缩和解压缩，可以和一些其他格式的图形文件进行转换。

rdjpgcom和wrjpgcom：用于在JFIF文件中插入和提取文字信息。

jpegtran：一个用于在不同的JPEG格式之间进行无损转换的工具。在这里cjpeg和djpeg就是很不错的profiling对象，有一定的复杂度，但又没有复杂到令人生畏。JPEG图像文件可以在互联网上灵活选取，基本原则是足够大，这样可以有比较长的运行时间来收集profiling数据，同时有足够的细节可以让软件充分的运行起来。网站上有很多大的图片，笔者选择的是一个2880x1800的JPEG文件。

Libjpeg可以在上找到。这里使用的版本是13-Jan-2013发布的release9。下载后的源文件是jpegsrc.v9.tar.gz三.GNUprofiler（gprof）简介GNUprofiler（gprof）是GNUBinutils（https://sourceware.org/binutils/）的一个组成部分，详细的文档可以在/binutils/docs/gprof/找到，默认情况下Linux系统当中都带有这个工具，不过如果打算在嵌入式开发板上用还是需要对GNUBinutils做交叉编译的。Gprof的功能：

1.生成“flatprofile”，包括每个函数的调用次数，每个函数消耗的处理器时间，

2.生成“Callgraph”，包括函数的调用关系，每个函数调用花费了多少时间。

3.生成“注释的源代码”，即是程序源代码的一个复本，标记有程序中每行代码的执行次数。Gprof的原理：

通过在编译和链接时使用-pg选项，gcc在应用程序的每个函数中都加入了一个名为mcount(也可能是”_mcount”或者”__mcount”,依赖于编译器或操作系统)的函数，这样应用程序里的每一个函数都会调用mcount,而mcount会在内存中保存一张函数调用图，记录通过函数调用堆栈找到的子函数和父函数的地址，以及所有与函数相关的调用时间，调用次数等信息。Gprof基本使用流程

1.在编译和链接时加上-pg选项。一般可以加在Makefile中的CFLAGS和LDFLAGS中。

2.执行编译的二进制程序。执行参数和方式同以前。

3.正常结束进程。这时内存中的信息会被写入到程序运行目录下的gmon.out文件中。

4.用gprof工具分析gmon.out文件。Gprof参数说明

Ÿ-b不再输出统计图表中每个字段的详细描述。

Ÿ-p只输出函数的调用图（Callgraph的那部分信息）。

Ÿ-q只输出函数的时间消耗列表。

Ÿ-eName不输出函数Name及其子函数的调用图（除非它们有未被限制的其它父函数）。可以给定多个-e标志。一个-e标志只能指定一个函数。

Ÿ-EName不输出函数Name及其子函数的调用图，此标志类似于-e标志，但它在总时间和百分比时间的计算中排除了由函数Name及其子函数所用的时间。

Ÿ-fName输出函数Name及其子函数的调用图。可以指定多个-f标志。一个-f标志只能指定一个函数。

Ÿ-FName输出函数Name及其子函数的调用图，它类似于-f标志，但它在总时间和百分比时间计算中仅使用所打印的例程的时间。可以指定多个-F标志。一个-F标志只能指定一个函数。-F标志覆盖-E标志。一般用法：

gprof-bELF_file_namegmon.out>report.txtGprof报告中flatprofile表格各列的说明：

%time:该函数消耗时间占程序所有时间百分比，全部相加应该是100%。

Cumulativeseconds:程序的累积执行时间，包括表格内该函数所在行之上的所有函数的执行时间

SelfSeconds:该函数本身的全部执行时间。表格会依照这列的数值按照降序排序所有行

Calls:函数被调用次数,如果无法确定则为空。

Selfms/call:函数平均执行时间。

Totalms/call:函数平均执行时间,包括其内部调用。

Name:函数名。在按照selfseconds和calls排序后再依照这列进行字母排序。Gprof报告中CallGraph表格各列的说明：

Index:索引值

%time:函数消耗时间占所有时间百分比

Self:函数本身执行时间

Children:执行子函数所用时间

Called:被调用次数

Name:函数名Gprof的优势：

1.简单易用。只需要在编译和链接是增加-pg选项。gprof对于代码大部分是用户空间的CPU密集型的应用程序用处明显，对于大部分时间运行在内核空间或者由于外部因素（例如操作系统的I/O子系统过载）而运行缓慢的应用程序则意义不大。

2.GNUBinutils的组成部分，基本上任何Linux里面都有。可以把生成的gmon.out拷贝到host上进行分析，省掉了一部分交叉编译的工作量。Gprof的劣势：

1.Gprof只够监控到编译和链接时有-pg选项的函数，工作在内核态的函数和没有加-pg编译的第三方库函数是无法被gprof监控到的。因此Gprof比较适合执行时间大部分在用户态的应用。在使用Gprof前最好用Linux下的time命令来确认应用程序的实际运行时间、用户空间运行时间、内核空间运行时间，以判断是否合适用gprof。Oprofile可以解决这一问题。2.Gprof不能监控sharedlibrary，即.so的文件。

对此有详细的分析。对这类文件可以用sprof，不过并不好用。变通的办法是将library静态链接到应用中，这样会增加应用程序的codesize。3.Gprof不支持多线程应用，多线程下只能采集主线程性能数据。原因是在多线程内只有主线程才能响应gprof采用的ITIMER_PROF信号。有一个简单的方法可以解决这