|
测试环境 1、Debug版本 2、
这里有一点需要注意:(还是举例吧),例如要分析视频编码中去块滤波器算法/程序的时耗,并不是一个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个部分考虑。 2、编译优化，现在很多编译器都实现了较强的代码优化功能，多数编译器都基于数据流分析以实现别名分析（通过变量重命名来消除数据相关，提高流水线的执行效率），常数折叠，公共子表达式消除、冗余代码删除，循环逆转和循环展开等与体系结构无关的优化，例如GNU gcc就是个很好的编译工具。还有借用并行程序设计技术，进行相关性分析，并通过相应技术是程序具有更好的局部性以提高Cache命中率。 对于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 
(myyb) |