x264的耗时分析与优化策略

测试环境
测试环境：Intel Pentium4 3.00GHz (双核cpu),开启超线程
内存:    DDR 1.00G
操作系统: Windows sever 2003 Enterprise Edition
分析软件: Intel(R) VTune(TM) Performance Analyzer 8.0(评估版lic)
编译软件: VC71+nasm0.98
Bus Speed: 800MHz
测试程序: X264 20060506 编码器

1、Debug版本
编码参数:
X264 -fps -o foreman.264 forman.cif 352x288
编码400frames,编码效率:23fps左右(libx264 debug版本),35fps(libx264 release版本)，提高了10fps以上，比较可观

2、
编码参数:
X264 -fps --no-asm -o foreman.264 forman.cif 352x288
--no-asm，Disable all CPU optimizations即未使用mmx,mmxext, sse,sse2,3dNow,3dnow ext,altivec等汇编指令优化。
编码400frames，编码效率2.67fps(libx264 debug版本),12.67fps(libx264 release版本),提高了10fps

Clockticks per Instructions Retired (CPI)表示该程序段的平均执行一条指令所需的时钟周期数,CPI越大表示该程序段调用的浮点数操作,乘法，除法，I/O处理，系统调用或文

件访问等代价昂贵的操作较多。
Instructions Retired events, 表示执行的指令数,越大表示该模块调用的较多.
Clockticks events 则表示该模块所消耗的时钟周期数,一般Clockticks events = Instructions Retired events * Clockticks per Instructions Retired (CPI),越大表示该模块消耗的时间越多,后面的Clockticks %则表示该模块的在所有程序中的时耗百分比.

这里有一点需要注意:(还是举例吧),例如要分析视频编码中去块滤波器算法/程序的时耗,并不是一个x264_frame_deblocking_filter函数的时间消耗就是所有x264编解码过程中的时间消耗,由于x264_frame_deblocking_filter调用deblck_edge,x264_clip3(该函数也被其他函数所调用)函数,而deblock_edge下又调用x264_deblock_v8_luma_mmxext, x264_deblock_h_luma_mmxext,x_264_deblock_h_chroma_mmxext, deblock_luma_intra_c, x264_deblock_v_chroma_mmxext（这些函数通过指针重定义的方式以适应于不同的硬件平台，比如Intel,AMD的CPU采用不同的指令系统，其实Mplayer,FFMPEG,T264等软件都采用类似的重定义方式,已达到一个软件使用与不同构架/平台，如arm,powerpc,x86等）等函数。那么这里如果统计去块滤波器的算法的时间消耗百分比，就需要将该函数及其所有调用的子函数的时间消耗都计算在内，x264_deblock_****都是唯一被deblock_edge调用，但对于x264_clip3，并不仅仅是去块滤波器部分调用，那么就只能部分计算在去块滤波器之内，至于部分是多少要根据个函数的调用次数，这里不确定。

相关x264时耗分析数据后面的表格。deblock占4.3%左右，quant+dequant占3.3%左右，DCT+IDCT占1.1%左右，主要是运动估计和运动补偿，ME中大量的sad/satd的计算，MC中的六阶滤波器tap_filter是主要时耗，具体我没有太细统计将近20%左右，x264中由于采用了算法优化，程序优化及mmx,sse,sse2等指令优化，将原本消耗较大的去块滤波器等都有了较大程度地优化。

这里再讨论一下程序性能优化技术，程序性能优化可以大致从3个部分考虑。
1、算法结构优化，实现同样的应用功能可采用多种不同的算法和方法，比如H.264种的运动估计全搜索和快速运动估计算法，实现的编码效率基本一致，但是处理时间可以节省10~20倍，所以需要选择高效的算法。还有递归算法非递归化，递归算法使得程序结构清晰，可读性高，但却需要执行大量的过程调用，堆栈保存等，运行效率低下。

2、编译优化，现在很多编译器都实现了较强的代码优化功能，多数编译器都基于数据流分析以实现别名分析（通过变量重命名来消除数据相关，提高流水线的执行效率），常数折叠，公共子表达式消除、冗余代码删除，循环逆转和循环展开等与体系结构无关的优化，例如GNU gcc就是个很好的编译工具。还有借用并行程序设计技术，进行相关性分析，并通过相应技术是程序具有更好的局部性以提高Cashe命中率。对于GCC中采用-O -O2 -O3 -O4等选项选择针对速度/面积等性能优化,另外debug版本由于程序中加入较多的debug参数,影响程序效率,上面x264的debug和release运行效率的对比可见一斑.编译优化属于静态优化，由编译器自动完成，但是编译器很难得到程序的语义信息，算法流程等信息。所以需要我们手工编程优化以最大程度提高程序运行效率

3、程序优化，包括a)使用inline函数，很多编译器支持inline关键字，减少函数调用开销却增加了代码量。b)针对程序运行平台，如x86(Intel)，Xscale，ARM，DSP等不同构架，可采用相应的汇编优化，将主要时耗部分/循环调用等，进行汇编指令优化MMX,SSE,WiMMX,ARM/Thumb指令,DSP汇编等，或者采用专用的库函数,如针对Intel CPU/Xscale构架的嵌入式系统（PXA255,PXA270等）可使用IPP/GPP库，提高程序效率。c)对于DSP系统，由于有多个并行处理单元，编译器会并行优化，所以需要尽量减少频繁小循环跳转，将循环展开，同时减少循环或内层循环也可以提高CPU的流线效率，尽量不断流。d)在Switch语句中根据发生频率排序case语句，编译器对于switch语句将生成if-else-if的嵌套代码，按概率排序可提高效率（FPGA/CPLD等逻辑器件中，采用VHDL语言描述的switch是生成多个逻辑器件，并且完全并行的）。e)减少函数调用参数. f)减少耗时的浮点数操作，除法操作等降低CPI