Chinaunix首页 | 论坛 | 博客
  • 博客访问: 492719
  • 博文数量: 196
  • 博客积分: 115
  • 博客等级: 民兵
  • 技术积分: 359
  • 用 户 组: 普通用户
  • 注册时间: 2010-05-13 23:19
文章分类

全部博文(196)

文章存档

2019年(5)

2018年(11)

2017年(16)

2016年(13)

2015年(46)

2014年(81)

2013年(22)

2012年(2)

分类: LINUX

2019-04-23 16:56:24

原文地址:性能优化方法和技巧 作者:robbielee

系列目录 性能优化方法和技巧

  1. 性能优化的方法和技巧:概述
  2. 性能优化的方法和技巧:代码
  3. 性能优化的方法和技巧:工具

这是一个可以用一本书来讲的话题,用一系列博客来讲,可能会比较单薄一点,这里只捡重要的说,忽略很多细节,当然以后还可以补充和扩展这个话题。

我以前就说过,性能优化有三个层次:

  • 系统层次
  • 算法层次
  • 代码层次

系统层次关注系统的控制流程和数据流程,优化主要考虑如何减少消息传递的个数;如何使系统的负载更加均衡;如何充分利用硬件的性能和设施;如何减少系统额外开销(比如上下文切换等)。

算法层次关注算法的选择(用更高效的算法替换现有算法,而不改变其接口);现有算法的优化(时间和空间的优化);并发和锁的优化(增加任务的并行性,减小锁的开销);数据结构的设计(比如lock-free的数据结构和算法)。

代码层次关注代码优化,主要是cache相关的优化(I-cache, D-cache相关的优化);代码执行顺序的调整;编译优化选项;语言相关的优化技巧等等。

性能优化需要相关的工具支持,这些工具包括编译器的支持;CPU的支持;以及集成到代码里面的测量工具等等。这些工具主要目的是测量代码的执行时间以及相关的cache miss, cache hit等数据,这些工具可以帮助开发者定位和分析问题。

性能优化和性能设计不同。性能设计贯穿于设计,编码,测试的整个环节,是产品生命周期的第一个阶段;而性能优化,通常是在现有系统和代码基础上所做 的改进,属于产品生命周期的后续几个阶段(假设产品有多个生命周期)。性能优化不是重新设计,性能优化是以现有的产品和代码为基础的,而不是推倒重来。性 能优化的方法和技巧可以指导性能设计,但两者的方法和技巧不能等同。两者关注的对象不同。性能设计是从正向考虑问题:如何设计出高效,高性能的系统;而性 能优化是从反向考虑问题:在出现性能问题时,如何定位和优化性能。性能设计考验的是开发者正向建设的能力,而性能优化考验的是开发者反向修复的能力。两者 可以互补。

后续我会就工具,架构,算法,代码,cache等方面展开讨论这个话题,敬请期待。

系列目录 性能优化方法和技巧

  1. 性能优化的方法和技巧:概述
  2. 性能优化的方法和技巧:代码
  3. 性能优化的方法和技巧:工具

“工欲善其事,必先利其器”(孔子),虽然“思想比工具更重要”(弯曲网友),但是,如果没有工具支持,性能优化就会非常累。思想不好掌握,但是使用工具还是比较好学习的,有了工具支持,可以让初级开发者更容易入门。

性能优化用到的工具,需要考虑哪些方面的问题?

1)使用工具是否需要重新编译代码?

  一般来说,性能优化工具基本上都需要重新编译代码。因为在生产环境里面使用的image,应该是已经优化过的image。不应该在用户环境里面去调试性能 问题。但Build-in的工具有一个好处就是性能测试所用的image和性能调试所用的image是相同的,这样可以避免重新编译所带来的误差。

2)工具本身对测量结果的影响

  如果是Build-in的工具,需要减小工具对性能的影响,启用工具和不启用工具对性能的影响应该在一定范围之内,比如5%,否则不清楚是工具本身影响性能还是被测量的代码性能下降。

  如果是需要重新编译使用的工具,这里的测试是一个相对值,不能做为性能指标的依据。因为编译会修改代码的位置,也可能会往代码里面加一个测量函数,它生成的image和性能测试的image不一样。

在这里要列出几个我用过的Linux工具,其他系统应该也有对应的工具,读者可以自己搜索。

性能测试工具一般分这么几种

1)收集CPU的performance counter。CPU里面有很多performance counter,打开之后,会记录CPU某些事件的数量,比如cache miss, 指令数,指令时间等等。这些counter需要编程才能使用。测量哪一段代码完全由自己掌握。

2)利用编译器的功能,在函数入口和出口自动加回调函数,在回调函数里面,记录入口和出口的时间。收集这些信息,可以得到函数的调用流程和每个函数所花费的时间。

3)自己在代码里面加入时间测量点,测量某段代码执行的时间。这种工具看起来和#1的作用差不多,但是由于performance counter编程有很多限制,所以这种工具有时还是有用处的。

在Linux里面,我们经常会用到

1)Oprofile

Oprofile已经加入了linux的内核代码库,所以不需要打patch,但是还需要重新编译内核才可以使用。这是使用最广泛的linux工具,网上有很多使用指南,读者可以自己搜索参考。

http://oprofile.sourceforge.net/news/

http://people.redhat.com/wcohen/Oprofile.pdf

2) KFT and Gprof

KFT是kernel的一个patch,只对kernel有效;Gprof是gcc里面的一个工具,只对用户空间的程序有效。这两个工具都需要重新 编译代码,它们都用到了gcc里面的finstrument-functions选项。编译时会在函数入口,出口加回调函数,而且inline函数也会改 成非inline的。它的工作原理可以参考:

http://blog.linux.org.tw/~jserv/archives/001870.html

http://blog.linux.org.tw/~jserv/archives/001723.html

http://elinux.org/Kernel_Function_Trace

http://www.network-theory.co.uk/docs/gccintro/gccintro_80.html

个人认为这是一个非常有用的工具,对读代码也有帮助,是居家旅行的必备。这里还有一个slide比较各种工具的,可以看看。

3) Performance counter

http://anton.ozlabs.org/blog/2009/09/04/using-performance-counters-for-linux/

Linux performance counter,用于收集CPU的performance counter,已经加入了内核代码库。通常来说,performance counter的粒度太大,基本没有什么用处,因为没法定位问题出在哪里;如果粒度太小,就需要手工编程,不能靠加几个检查点就可以了。所以还是要结合上 面两个工具一起用才有好的效果。

工具解决哪些问题?

1)帮助建立基线。没有基线,就没办法做性能优化。性能优化是个迭代的过程,指望一次搞定是不现实的。

2)帮助定位问题。这里有两个涵义:一是性能问题出现在什么地方,是由哪一段代码引起的;二是性能问题的原因,cache miss,TLB miss还是其他。

3)帮助验证优化方案。优化的结果应该能在工具里面体现出来,而不是靠蒙。

就这些了,还有什么补充?

参考资料

1)http://software.intel.com/en-us/articles/intel-microarchitecture-codename-nehalem-performance-monitoring-unit-programming-guide/

2)  http://www.celinuxforum.org/CelfPubWiki/KernelInstrumentation


3)  Continuous Profiling: Where Have All the Cycles Gone?



系列目录 性能优化方法和技巧

  1. 性能优化的方法和技巧:概述
  2. 性能优化的方法和技巧:代码
  3. 性能优化的方法和技巧:工具

代码层次的优化是最直接,也是最简单的,但前提是要对代码很熟悉,对系统很熟悉。很多事情做到后来,都是一句话:无他,但手熟尔^-^。

在展开这个话题之前,有必要先简单介绍一下Cache相关的内容,如果对这部分内容不熟悉,建议先补补课,做性能优化对Cache不了解,基本上就是盲人骑瞎马。

Cache一般来说,需要关心以下几个方面

1)Cache hierarchy

Cache的层次,一般有L1, L2, L3 (L是level的意思)的cache。通常来说L1,L2是集成  在CPU里面的(可以称之为On-chip cache),而L3是放在CPU外面(可以称之为Off-chip  cache)。当然这个不是绝对的,不同CPU的做法可能会不太一样。这里面应该还需要加上  register,虽然register不是cache,但是把数据放到register里面是能够提高性能的。

2)Cache size

Cache的容量决定了有多少代码和数据可以放到Cache里面,有了Cache才有了竞争,才有   了替换,才有了优化的空间。如果一个程序的热点(hotspot)已经完全填充了整个Cache,那   么再从Cache角度考虑优化就是白费力气了,巧妇难为无米之炊。我们优化程序的目标是把   程序尽可能放到Cache里面,但是把程序写到能够占满整个Cache还是有一定难度的,这么大   的一个Code path,相应的代码得有多少,代码逻辑肯定是相当的复杂(基本上是不可能,至少   我没有见过)。

3)Cache line size

CPU从内存load数据是一次一个cache line;往内存里面写也是一次一个cache line,所以一个   cache line里面的数据最好是读写分开,否则就会相互影响。

4)Cache associative

Cache的关联。有全关联(full associative),内存可以映射到任意一个Cache line;也有N-way   关联,这个就是一个哈希表的结构,N就是冲突链的长度,超过了N,就需要替换。

5)Cache type

有I-cache(指令cache),D-cache(数据cache),TLB(MMU的cache),每一种又有L1,   L2等等,有区分指令和数据的cache,也有不区分指令和数据的cache。

更多与cache相关的知识,可以参考这个链接:

http://en.wikipedia.org/wiki/CPU_cache

或者是附件里面的cache.pdf,里面有一个简单的总结。

代码层次的优化,主要是从以下两个角度考虑问题:

1)I-cache相关的优化

例如精简code path,简化调用关系,减少冗余代码等等。尽量减少不必要的调用。但是有用还是无用,是和应用相关的,所以代码层次的优化很多是针对某个应用或者性能指标的优化。有针对性的优化,更容易得到可观的结果。

2)D-cache相关的优化

减少D-cache miss的数量,增加有效的数据访问的数量。这个要比I-cache优化难一些。

下面是一个代码优化技巧列表,需要不断地补充,优化和筛选。

1) Code adjacency (把相关代码放在一起),推荐指数:5颗星

把相关代码放在一起有两个涵义,一是相关的源文件要放在一起;二是相关的函数在object文件  里面,也应该是相邻的。这样,在可执行文件被加载到内存里面的时候,函数的位置也是相邻的。  相邻的函数,冲突的几率比较小。而且相关的函数放在一起,也符合模块化编程的要求:那就是  高内聚,低耦合。

如果能够把一个code path上的函数编译到一起(需要编译器支持,把相关函数编译到一起),  很显然会提高I-cache的命中率,减少冲突。但是一个系统有很多个code path,所以不可能面  面俱到。不同的性能指标,在优化的时候可能是冲突的。所以尽量做对所以case都有效的优化,  虽然做到这一点比较难。

2) Cache line alignment (cache对齐),推荐指数:4颗星

数据跨越两个cache line,就意味着两次load或者两次store。如果数据结构是cache line对齐的,  就有可能减少一次读写。数据结构的首地址cache line对齐,意味着可能有内存浪费(特别是  数组这样连续分配的数据结构),所以需要在空间和时间两方面权衡。

3) Branch prediction (分支预测),推荐指数:3颗星

代码在内存里面是顺序排列的。对于分支程序来说,如果分支语句之后的代码有更大的执行几率,  那么就可以减少跳转,一般CPU都有指令预取功能,这样可以提高指令预取命中的几率。分支预测  用的就是likely/unlikely这样的宏,一般需要编译器的支持,这样做是静态的分支预测。现在也有  很多CPU支持在CPU内部保存执行过的分支指令的结果(分支指令的cache),所以静态的分支预测  就没有太多的意义。如果分支是有意义的,那么说明任何分支都会执行到,所以在特定情况下,静态 分支预测的结果并没有多好,而且likely/unlikely对代码有很大的侵害(影响可读性),所以一般不  推荐使用这个方法。

4) Data prefetch (数据预取),推荐指数:4颗星

指令预取是CPU自动完成的,但是数据预取就是一个有技术含量的工作。数据预取的依据是预取的数据  马上会用到,这个应该符合空间局部性(spatial locality),但是如何知道预取的数据会被用到,这个  要看上下文的关系。一般来说,数据预取在循环里面用的比较多,因为循环是最符合空间局部性的代码。

但是数据预取的代码本身对程序是有侵害的(影响美观和可读性),而且优化效果不一定很明显(命中  的概率)。数据预取可以填充流水线,避免访问内存的等待,还是有一定的好处的。

5) Memory coloring (内存着色),推荐指数:不推荐

内存着色属于系统层次的优化,在代码优化阶段去考虑内存着色,有点太晚了。所以这个话题可以放到  系统层次优化里面去讨论。

6)Register parameters (寄存器参数),推荐指数:4颗星

寄存器做为速度最快的内存单元,不好好利用实在是浪费。但是,怎么用?一般来说,函数调用的参数  少于某个数,比如3,参数是通过寄存器传递的(这个要看ABI的约定)。所以,写函数的时候,不要  带那么多参数。c语言里还有一个register关键词,不过通常都没什么用处(没试过,不知道效果,不过  可以反汇编看看具体的指令,估计是和编译器相关)。尝试从寄存器里面读取数据,而不是内存。

7) Lazy computation (延迟计算),推荐指数:5颗星

延迟计算的意思是最近用不上的变量,就不要去初始化。通常来说,在函数开始就会初始化很多数据,但是  这些数据在函数执行过程中并没有用到(比如一个分支判断,就退出了函数),那么这些动作就是浪费了。

变量初始化是一个好的编程习惯,但是在性能优化的时候,有可能就是一个多余的动作,需要综合考虑函数  的各个分支,做出决定。

延迟计算也可以是系统层次的优化,比如COW(copy-on-write)就是在fork子进程的时候,并没有复制父  进程所有的页表,而是只复制指令部分。当有写发生的时候,再复制数据部分,这样可以避免不必要的复制,  提供进程创建的速度。

8] Early computation (提前计算),推荐指数:5颗星

有些变量,需要计算一次,多次使用的时候。最好是提前计算一下,保存结果,以后再引用,避免每次都  重新计算一次。函数多了,有时就会忽略这个函数都做了些什么,写程序的人可以不了解,但是优化的时候  不能不了解。能使用常数的地方,尽量使用常数,加减乘除都会消耗CPU的指令,不可不查。

9)Inline or not inline (inline函数),推荐指数:5颗星

Inline or not inline,这是个问题。Inline可以减少函数调用的开销(入栈,出栈的操作),但是inline也  有可能造成大量的重复代码,使得代码的体积变大。Inline对debug也有坏处(汇编和语言对不上)。所以  用这个的时候要谨慎。小的函数(小于10行),可以尝试用inline;调用次数多的或者很长的函数,尽量不  要用inline。

10) Macro or not macro (宏定义或者宏函数),推荐指数:5颗星

Macro和inline带来的好处,坏处是一样的。但我的感觉是,可以用宏定义,不要用宏函数。用宏写函数,  会有很多潜在的危险。宏要简单,精炼,最好是不要用。中看不中用。

11) Allocation on stack (局部变量),推荐指数:5颗星

如果每次都要在栈上分配一个1K大小的变量,这个代价是不是太大了哪?如果这个变量还需要初始化(因  为值是随机的),那是不是更浪费了。全局变量好的一点是不需要反复的重建,销毁;而局部变量就有这个  坏处。所以避免在栈上使用数组等变量。

12) Multiple conditions (多个条件的判断语句),推荐指数:3颗星

多个条件判断时,是一个逐步缩小范围的过程。条件的先后,决定了前面的判断是否多余的。根据code path  的情况和条件分支的几率,调整条件的顺序,可以在一定程度上减少code path的开销。但是这个工作做  起来有点难度,所以通常不推荐使用。

13) Per-cpu data structure (非共享的数据结构),推荐指数:5颗星

Per-cpu data structure 在多核,多CPU或者多线程编程里面一个通用的技巧。使用Per-cpu data  structure的目的是避免共享变量的锁,使得每个CPU可以独立访问数据而与其他CPU无关。坏处是会  消耗大量的内存,而且并不是所有的变量都可以per-cpu化。并行是多核编程追求的目标,而串行化  是多核编程里面最大的伤害。有关并行和串行的话题,在系统层次优化里面还会提到。

局部变量肯定是thread local的,所以在多核编程里面,局部变量反而更有好处。

14) 64 bits counter in 32 bits environment (32位环境里的64位counter),推荐指数:5颗星

32位环境里面用64位counter很显然会影响性能,所以除非必要,最好别用。有关counter的优化可以多  说几句。counter是必须的,但是还需要慎重的选择,避免重复的计数。关键路径上的counter可以使用  per-cpu counter,非关键路径(exception path)就可以省一点内存。

15) Reduce call path or call trace (减少函数调用的层次),推荐指数:4颗星

函数越多,有用的事情做的就越少(函数的入栈,出栈等)。所以要减少函数的调用层次。但是不应该  破坏程序的美观和可读性。个人认为好程序的首要标准就是美观和可读性。不好看的程序读起来影响心  情。所以需要权衡利弊,不能一个程序就一个函数。

16) Move exception path out (把exception处理放到另一个函数里面),推荐指数:5颗星

把exception path和critical path放到一起(代码混合在一起),就会影响critical path的cache性能。  而很多时候,exception path都是长篇大论,有点喧宾夺主的感觉。如果能把critical path和  exception path完全分离开,这样对i-cache有很大帮助。

17) Read, write split (读写分离),推荐指数:5颗星

cache.pdf里面提到了伪共 享(false sharing),就是说两个无关的变量,一个读,一个写,而这  两个变量在一个cache line里面。那么写会导致cache line失效(通常是在多核编程里面,两个变量  在不同的core上引用)。读写分离是一个很难运用的技巧,特别是在code很复杂的情况下。需要  不断地调试,是个力气活(如果有工具帮助会好一点,比如cache miss时触发cpu的execption处理  之类的)。

18) Reduce duplicated code(减少冗余代码),推荐指数:5颗星

代码里面的冗余代码和死代码(dead code)很多。减少冗余代码就是减小浪费。但冗余代码有时  又是必不可少(copy-paste太多,尾大不掉,不好改了),但是对critical path,花一些功夫还  是必要的。

19) Use compiler optimization options (使用编译器的优化选项),推荐指数:4颗星

  使用编译器选项来优化代码,这个应该从一开始就进行。写编译器的人更懂CPU,所以可以放心  地使用。编译器优化有不同的目标,有优化空间的,有优化时间的,看需求使用。

20) Know your code path (了解所有的执行路径,并优化关键路径),推荐指数:5颗星

  代码的执行路径和静态代码不同,它是一个动态的执行过程,不同的输入,走过的路径不同。  我们应该能区分出主要路径和次要路径,关注和优化主要路径。要了解执行路径的执行流程,  有多少个锁,多少个原子操作,有多少同步消息,有多少内存拷贝等等。这是性能优化里面 必不可少,也是唯一正确的途径,优化的过程,也是学习,整理知识的过程,虽然有时很无聊,  但有时也很有趣。

代码优化有时与编程规则是冲突的,比如直接访问成员变量,还是通过接口来访问。编程规则上肯定是说要通过接口来访问,但直接访问效率更高。还有就是 许多ASSERT之类的代码,加的多了,也影响性能,但是不加又会给debug带来麻烦。所以需要权衡。代码层次的优化是基本功课,但是指望代码层次的优 化来解决所有问题,无疑是缘木求鱼。从系统层次和算法层次考虑问题,可能效果会更好。

代码层次的优化需要相关工具的配合,没有工具,将会事倍功半。所以在优化之前,先把工具准备好。有关工具的话题,会在另一篇文章里面讲。

还有什么,需要好好想想。这些优化技巧都是与c语言相关的。对于其他语言不一定适用。每个语言都有一些与性能相关的编码规范和约定俗成,遵守就可以了。有很多Effective, Exceptional 系列的书籍,可以看看。

代码相关的优化,着力点还是在代码上,多看,多想,就会有收获。

参考资料:

1)http://en.wikipedia.org/wiki/CPU_cache

2)  Effective C++: 55 Specific Ways to Improve Your Programs and Designs (3rd Edition)

3)  More Effective C++: 35 New Ways to Improve Your Programs and Designs

4) Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library

5) Effective Java (2nd Edition)

6) Effective C# (Covers C# 4.0): 50 Specific Ways to Improve Your C# (2nd Edition) (Effective Software Development Series)

7) The Elements of Cache Programming Style

阅读(725) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册