龙芯处理器性能分析平台的搭建以及结果.pdf

龙芯处理器性能分析平台的搭建以及结果 龙芯处理器性能分析平台的搭建以及结果 邹琼 （1.中国科学技术大学 计算机科学技术系 合肥 安徽 230000） (2. 中国科学院计算技术研究所 微处理器中心 北京 100080) 摘摘 要要：随着处理器技术的日新月异，设计一款高性能的处理器对于处理器开发人员是一个挑战，他们对处理器性能进行细粒度的分析才能拥有好的设计思路，因此拥有性能分析平台是一个必不可少的条件，本篇文章介绍了目前龙芯处理器的性能分析平台，通过性能分析平台的帮助，spec2000 int 程序性能提高了12.8%，spec2000 float 程序性能提高了 11.9%，同时为下一代龙芯处理器的设计提供了帮助，并且也证明了目前的性能分析方法是可行的它的优势更加体现在保证分析精确准确的前提下，没有带来过多的硬件开销 关键词关键词：龙芯处理器，性能分析，性能分析计数器，gprof，GLTO Profiler Implementationof Performance Analysis Platform for GODSON Processor zouqiong (1.Univercity of Science and Technology of China, Heifei, Anhui, 230000，China) (2. Institute of Computing Technology, Chinese Academy of Sciences, Beijing, 100080, China) E-mail: zouqiong @ Abstract: With the improving of the chip technology, it is really a challenge for a CPU designer to design a chip with high performance. A good design requires analyzing the interaction of the application and the underlying architecture. So a platform for performance analyzing is absolutely necessarily. In this paper, we describe the platform now we used in GODSON processor, with the help of which, we achieve a speedup of 12.8% in spec2000 int application, 11.9% in spec2000 float application. Also, it gives us a clue for the next generation of GODSON processor, and make our platform suitable for performance analysis. Keywords：GODSON, performance analysis, performance counter, Gprof, GLTO Profiler 1 引言 1 引言 对于性能分析人员而言， 必须知道程序 的时间都消耗在什么地方， 时间都是如何消 耗掉的。

目前采用的方法有三种，一种是通 过模拟器[3,4]，它能够详细记录处理器以及 存储系统发生的所有事件， 但是准确的模拟 处理器行为无疑使得模拟的过程漫长无比 第二种方法是通过软件插桩的方法[5,6,7]， 这种方法的速度可以容忍， 但是无法准确的 估计出程序的动态行为，精确度不够第三 种方法就是硬件计数器的方法[7,8,9,10,11]，它具有快速、精确的特点，但是带来了硬件 上的开销 本文介绍了目前龙芯处理器[1]中采用 的性能分析方法， 它结合了第二种方法和第 三种方法的优点， 一方面加快了性能分析的 速度和精度， 另一方面也节省了硬件上的开 销经过实践证明，这种性能分析的方法使 得spec2000程 序 性 能 平 均 提 高 了 11.9%~12.8%，部分程序性能提高超过了 15%，个别程序提高超过了 30% 本文接下来是这样组织的， 第 2 节介绍 了硬件计数器在龙芯处理器性能分析上的 不足， 从而进一步提出了现阶段采用的性能基金项目基金项目：1. 国家自然科学基金杰出青年基金项目“计算机系统结构研究（60325205）” 2. 国家 863 重点项目“高性能通用 CPU 芯片全定制实 现及系统集成（2002AA110010）”,“龙芯 2 号增强型处理器芯片设计(2005AA110010)”,“中法合作 90 纳米工艺龙芯 CPU 设计(2005AA119020)“ 3. 国家中点基础研究发展计划(2005CB321600) 4.计算所基础研究基金项目(20056020) 5.中科院计算所知识创新课题(20056240 20066012) 6.国家自 然科学基金项目(60673146) 分析的方法和流程，第 3 节主要是基于第 2 节提出的性能分析方法对 spec2000 程序进 行分析， 第4节给出了优化的手段以及结果， 第 5 节是未来展望。

2 性能分析工具简介以及流程 2 性能分析工具简介以及流程 2.1 目前的性能分析方法以及不足 对程序的性能进行调整， 就必须能够发 现程序的瓶颈所在，目前有三种方法，一种 是使用模拟器来运行程序， 精确但是速度无 法忍受，第二种是对程序插桩，比如 gprof[11]，它需要编译器在对程序进行编译 的时候对程序进行插桩， 经过插桩的程序虽 然可以得到程序的概况图， 但是却无法得到 任何处理器细节上的信息， 我们可以知道程 序中的热点函数， 但是却无法定位该函数中 的瓶颈，也无法预知程序的动态行为，速度 快但是精确度不够 第三种方法就是性能计数器， 它负责统 计处理器某些事件发生的次数， 然后由相应 的性能分析软件来对事件发生的次数进行 处理， 它能够将程序运行时候的处理器的状 态映射到程序中的具体位置， 我们可以发现 热点函数中频繁 cache 不命中的地点所在等 等，性能分析器精确并且速度快现代的通 用 处 理 器 ,Intel Pentium[8] ， IBM Power2[7,9]，DEC Alpha[10]， MIPSR10000[11]中都实现了性能计数器， 并 且提供了相应的应用程序接口， 两者的密切 结合有助于定位程序的瓶颈所在。

目前龙芯处理器中加入了两个性能计 数器，总共可统计１６个不同的事件，包括 对统计多层次访存结构的动态行为以及转 移猜测的准确率等等， 性能计数器为我们定 位程序的瓶颈提供了方便 同时我们也看到 了我们目前的性能计数器的不足之处， 性能 计数器必须和软件很好的结合才能发挥最 大的优势，Sun 公司有一系列软件 collect analyzer 等等，他们与性能计数器的完美结 合使得性能分析游刃有余，Intel 公司的 Vtune analyzer 也是一个很好的例子而对 于目前的龙芯处理器， 与计数器配套的分析 软件尚不完善(下面简称 perfctr)，并且考虑到硬件上的开销，可以统计的事件仅有 16 项因此为了很好的进行性能分析的工作， 我 们 必 须 借 助 其 他 的 工 具 (GLTO[2] profiler，Gprof)，这些工具弥补了 perfctr 的 不足之处，三者的结合能够做到 Vtune analyzer，collect analyzer 等性能分析器所能 够做的工作，同时硬件上的开销小于它们 下面将一一介绍性能分析平台中所使用的 其它工具 2.2 Gprof 分析工具 对程序进行性能分析， 首先要找出热点 函数， 而 perfctr 无法做到这一点， 从而导致 后续的性能分析工作无法继续。

因此首要任 务就是找到热点函数所在(热点函数包括频 繁调用的函数以及长时间运行的函数) 为此， 我们使用Gprof来完成这个工作 Gprof 是 GNU 提供的统计工具，主要用来 显示调用图概要分析数据， 使用它可以生成 C、Pascal、Fortran 或 COBOL 程序的执行 概要文件，使用它将得到以下三项结果： 1. 平面概要文件：此文件（图 1）按照时 间递减的顺序给出了程序中每个函数 的执行时间和调用次数 （图 1 中的 time 列和 seconds 列） 我们从图 1 中便知道 了 253.eon 程序的热点函数 2. 调用图： 按照程序中各个函数存在的时 间排序， 函数存在的时间包括其调用子 函数的时间 在每个功能项的下方列出 了其（直接）调用图的子代，并附有如 何将它们的时间传播到此功能的指示 在此函数的上方类似地显示了如何将 此函数及其后代的时间传播给它的 （直 接）调用图父代 3. 同时还显示了周期， 包括整个周期项和 该周期的成员列表以及这些成员在该 周期中占用的时间和调用次数 图 1: 253.eon 的执行概要图 2.3 GODSON 链接时优化器的 Profiler 机制 通过 Gprof[11]，我们可以方便的得到 热点函数信息以及函数调用关系。

当热点函 数较小的时候， 可以很容易看出程序的瓶颈 所在，然而当热点函数比较庞大的时候，从 中找出瓶颈的难度就大大增加了这个时 候，我们需要一个能够找出热点基本块(即 运行时间很长或频繁被执行)，并能够进一 步定位频繁执行或长时间执行的指令的软 件 GLTO （ 全 称Godson Link Time Optimizer） [2]是针对龙芯处理器的体系结构 和指令集的特征的链接后优化器GLTO[2] 中实现了一些 profile 机制（主要是针对 branch likely 指令和热点基本块） 它能够在 可执行文件中插入代码，可以针对某条指 令， 或某个基本块搜集运行的情况， 比 GNU 的 gprof 搜集信息的粒度更小，更加精确、 灵活于是我们对 GLTO 现有的 profiler 机 制进行了修改， 使得其可以统计程序运行时 的各种行为， 比如可以统计热点函数的条件 分支指令个数，无条件分支指令个数等等， 这些机制弥补了 perfctr 无法针对基本块、 单 条指令进行统计的缺陷， 为下一步性能分析 做了良好的铺垫 2.4 性能分析流程 1. 使用 gprof 得到程序中每个函数的总执 行时间和调用计数， 针对总执行时间和调用 计数特别突出的函数进行分析，以 253.eon 为例，图 1 是通过 gprof 统计的执行概要图 的一部分， 通过该图我们发现该程序运行时 间均匀的分布在各个函数中， 其中有大量的 函数被频繁的调用， 而 eon 本身是用 C++语 言编写的程序，其中使用了大量的虚函数， 因虚函数调用每次都要通过虚表查询的特 性我们可以断定， 该程序中函数的调用开销 不菲。

2. 在 1 分析的基础上， 我们对 GLTO 进行 修改， 使得其可以针对 1 中找出的热点函数 统计其中执行的各种指令的次数， 而对于目 前的应用程序(计算密集型程序除外)，大量 的开销都是由于分支预测错误和访存失效 带来的，因此我们主要统计了 spec2000 程 序中访存指令和转移指令个数 以条件分支 指令为例，我们发现虽然 176.gcc 中函数 propagate_block 的运行时间占到总运行时 间的 10.10%，但是他的运行时条件分支指 令个数占运行时的条件分支指令总数的 35.4%，也就是说 propagate_block 的运行时 间很大一部分取决于转移猜测的正确率 3. 利用性能分析计数器来统计指令 cache 失效率， 数据 cache 失效率， 指令 TLB 失效 。