optimization.txt 10 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276
  1. optimization Tips (for libavcodec):
  2. ===================================
  3. What to optimize:
  4. -----------------
  5. If you plan to do non-x86 architecture specific optimizations (SIMD normally),
  6. then take a look in the x86/ directory, as most important functions are
  7. already optimized for MMX.
  8. If you want to do x86 optimizations then you can either try to fine-tune the
  9. stuff in the x86 directory or find some other functions in the C source to
  10. optimize, but there aren't many left.
  11. Understanding these overoptimized functions:
  12. --------------------------------------------
  13. As many functions tend to be a bit difficult to understand because
  14. of optimizations, it can be hard to optimize them further, or write
  15. architecture-specific versions. It is recommended to look at older
  16. revisions of the interesting files (web frontends for the various FFmpeg
  17. branches are listed at http://ffmpeg.org/download.html).
  18. Alternatively, look into the other architecture-specific versions in
  19. the x86/, ppc/, alpha/ subdirectories. Even if you don't exactly
  20. comprehend the instructions, it could help understanding the functions
  21. and how they can be optimized.
  22. NOTE: If you still don't understand some function, ask at our mailing list!!!
  23. (http://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel)
  24. When is an optimization justified?
  25. ----------------------------------
  26. Normally, clean and simple optimizations for widely used codecs are
  27. justified even if they only achieve an overall speedup of 0.1%. These
  28. speedups accumulate and can make a big difference after awhile. Also, if
  29. none of the following factors get worse due to an optimization -- speed,
  30. binary code size, source size, source readability -- and at least one
  31. factor improves, then an optimization is always a good idea even if the
  32. overall gain is less than 0.1%. For obscure codecs that are not often
  33. used, the goal is more toward keeping the code clean, small, and
  34. readable instead of making it 1% faster.
  35. WTF is that function good for ....:
  36. -----------------------------------
  37. The primary purpose of this list is to avoid wasting time optimizing functions
  38. which are rarely used.
  39. put(_no_rnd)_pixels{,_x2,_y2,_xy2}
  40. Used in motion compensation (en/decoding).
  41. avg_pixels{,_x2,_y2,_xy2}
  42. Used in motion compensation of B-frames.
  43. These are less important than the put*pixels functions.
  44. avg_no_rnd_pixels*
  45. unused
  46. pix_abs16x16{,_x2,_y2,_xy2}
  47. Used in motion estimation (encoding) with SAD.
  48. pix_abs8x8{,_x2,_y2,_xy2}
  49. Used in motion estimation (encoding) with SAD of MPEG-4 4MV only.
  50. These are less important than the pix_abs16x16* functions.
  51. put_mspel8_mc* / wmv2_mspel8*
  52. Used only in WMV2.
  53. it is not recommended that you waste your time with these, as WMV2
  54. is an ugly and relatively useless codec.
  55. mpeg4_qpel* / *qpel_mc*
  56. Used in MPEG-4 qpel motion compensation (encoding & decoding).
  57. The qpel8 functions are used only for 4mv,
  58. the avg_* functions are used only for B-frames.
  59. Optimizing them should have a significant impact on qpel
  60. encoding & decoding.
  61. qpel{8,16}_mc??_old_c / *pixels{8,16}_l4
  62. Just used to work around a bug in an old libavcodec encoder version.
  63. Don't optimize them.
  64. add_bytes/diff_bytes
  65. For huffyuv only, optimize if you want a faster ffhuffyuv codec.
  66. get_pixels / diff_pixels
  67. Used for encoding, easy.
  68. clear_blocks
  69. easiest to optimize
  70. gmc
  71. Used for MPEG-4 gmc.
  72. Optimizing this should have a significant effect on the gmc decoding
  73. speed.
  74. gmc1
  75. Used for chroma blocks in MPEG-4 gmc with 1 warp point
  76. (there are 4 luma & 2 chroma blocks per macroblock, so
  77. only 1/3 of the gmc blocks use this, the other 2/3
  78. use the normal put_pixel* code, but only if there is
  79. just 1 warp point).
  80. Note: DivX5 gmc always uses just 1 warp point.
  81. pix_sum
  82. Used for encoding.
  83. hadamard8_diff / sse / sad == pix_norm1 / dct_sad / quant_psnr / rd / bit
  84. Specific compare functions used in encoding, it depends upon the
  85. command line switches which of these are used.
  86. Don't waste your time with dct_sad & quant_psnr, they aren't
  87. really useful.
  88. put_pixels_clamped / add_pixels_clamped
  89. Used for en/decoding in the IDCT, easy.
  90. Note, some optimized IDCTs have the add/put clamped code included and
  91. then put_pixels_clamped / add_pixels_clamped will be unused.
  92. idct/fdct
  93. idct (encoding & decoding)
  94. fdct (encoding)
  95. difficult to optimize
  96. dct_quantize_trellis
  97. Used for encoding with trellis quantization.
  98. difficult to optimize
  99. dct_quantize
  100. Used for encoding.
  101. dct_unquantize_mpeg1
  102. Used in MPEG-1 en/decoding.
  103. dct_unquantize_mpeg2
  104. Used in MPEG-2 en/decoding.
  105. dct_unquantize_h263
  106. Used in MPEG-4/H.263 en/decoding.
  107. Alignment:
  108. Some instructions on some architectures have strict alignment restrictions,
  109. for example most SSE/SSE2 instructions on x86.
  110. The minimum guaranteed alignment is written in the .h files, for example:
  111. void (*put_pixels_clamped)(const int16_t *block/*align 16*/, uint8_t *pixels/*align 8*/, ptrdiff_t stride);
  112. General Tips:
  113. -------------
  114. Use asm loops like:
  115. __asm__(
  116. "1: ....
  117. ...
  118. "jump_instruction ....
  119. Do not use C loops:
  120. do{
  121. __asm__(
  122. ...
  123. }while()
  124. For x86, mark registers that are clobbered in your asm. This means both
  125. general x86 registers (e.g. eax) as well as XMM registers. This last one is
  126. particularly important on Win64, where xmm6-15 are callee-save, and not
  127. restoring their contents leads to undefined results. In external asm,
  128. you do this by using:
  129. cglobal function_name, num_args, num_regs, num_xmm_regs
  130. In inline asm, you specify clobbered registers at the end of your asm:
  131. __asm__(".." ::: "%eax").
  132. If gcc is not set to support sse (-msse) it will not accept xmm registers
  133. in the clobber list. For that we use two macros to declare the clobbers.
  134. XMM_CLOBBERS should be used when there are other clobbers, for example:
  135. __asm__(".." ::: XMM_CLOBBERS("xmm0",) "eax");
  136. and XMM_CLOBBERS_ONLY should be used when the only clobbers are xmm registers:
  137. __asm__(".." :: XMM_CLOBBERS_ONLY("xmm0"));
  138. Do not expect a compiler to maintain values in your registers between separate
  139. (inline) asm code blocks. It is not required to. For example, this is bad:
  140. __asm__("movdqa %0, %%xmm7" : src);
  141. /* do something */
  142. __asm__("movdqa %%xmm7, %1" : dst);
  143. - first of all, you're assuming that the compiler will not use xmm7 in
  144. between the two asm blocks. It probably won't when you test it, but it's
  145. a poor assumption that will break at some point for some --cpu compiler flag
  146. - secondly, you didn't mark xmm7 as clobbered. If you did, the compiler would
  147. have restored the original value of xmm7 after the first asm block, thus
  148. rendering the combination of the two blocks of code invalid
  149. Code that depends on data in registries being untouched, should be written as
  150. a single __asm__() statement. Ideally, a single function contains only one
  151. __asm__() block.
  152. Use external asm (nasm/yasm) or inline asm (__asm__()), do not use intrinsics.
  153. The latter requires a good optimizing compiler which gcc is not.
  154. When debugging a x86 external asm compilation issue, if lost in the macro
  155. expansions, add DBG=1 to your make command-line: the input file will be
  156. preprocessed, stripped of the debug/empty lines, then compiled, showing the
  157. actual lines causing issues.
  158. Inline asm vs. external asm
  159. ---------------------------
  160. Both inline asm (__asm__("..") in a .c file, handled by a compiler such as gcc)
  161. and external asm (.s or .asm files, handled by an assembler such as nasm/yasm)
  162. are accepted in FFmpeg. Which one to use differs per specific case.
  163. - if your code is intended to be inlined in a C function, inline asm is always
  164. better, because external asm cannot be inlined
  165. - if your code calls external functions, external asm is always better
  166. - if your code takes huge and complex structs as function arguments (e.g.
  167. MpegEncContext; note that this is not ideal and is discouraged if there
  168. are alternatives), then inline asm is always better, because predicting
  169. member offsets in complex structs is almost impossible. It's safest to let
  170. the compiler take care of that
  171. - in many cases, both can be used and it just depends on the preference of the
  172. person writing the asm. For new asm, the choice is up to you. For existing
  173. asm, you'll likely want to maintain whatever form it is currently in unless
  174. there is a good reason to change it.
  175. - if, for some reason, you believe that a particular chunk of existing external
  176. asm could be improved upon further if written in inline asm (or the other
  177. way around), then please make the move from external asm <-> inline asm a
  178. separate patch before your patches that actually improve the asm.
  179. Links:
  180. ======
  181. http://www.aggregate.org/MAGIC/
  182. x86-specific:
  183. -------------
  184. http://developer.intel.com/design/pentium4/manuals/248966.htm
  185. The IA-32 Intel Architecture Software Developer's Manual, Volume 2:
  186. Instruction Set Reference
  187. http://developer.intel.com/design/pentium4/manuals/245471.htm
  188. http://www.agner.org/assem/
  189. AMD Athlon Processor x86 Code Optimization Guide:
  190. http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22007.pdf
  191. ARM-specific:
  192. -------------
  193. ARM Architecture Reference Manual (up to ARMv5TE):
  194. http://www.arm.com/community/university/eulaarmarm.html
  195. Procedure Call Standard for the ARM Architecture:
  196. http://www.arm.com/pdfs/aapcs.pdf
  197. Optimization guide for ARM9E (used in Nokia 770 Internet Tablet):
  198. http://infocenter.arm.com/help/topic/com.arm.doc.ddi0240b/DDI0240A.pdf
  199. Optimization guide for ARM11 (used in Nokia N800 Internet Tablet):
  200. http://infocenter.arm.com/help/topic/com.arm.doc.ddi0211j/DDI0211J_arm1136_r1p5_trm.pdf
  201. Optimization guide for Intel XScale (used in Sharp Zaurus PDA):
  202. http://download.intel.com/design/intelxscale/27347302.pdf
  203. Intel Wireless MMX 2 Coprocessor: Programmers Reference Manual
  204. http://download.intel.com/design/intelxscale/31451001.pdf
  205. PowerPC-specific:
  206. -----------------
  207. PowerPC32/AltiVec PIM:
  208. www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPEM.pdf
  209. PowerPC32/AltiVec PEM:
  210. www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPIM.pdf
  211. CELL/SPU:
  212. http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/30B3520C93F437AB87257060006FFE5E/$file/Language_Extensions_for_CBEA_2.4.pdf
  213. http://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/9F820A5FFA3ECE8C8725716A0062585F/$file/CBE_Handbook_v1.1_24APR2007_pub.pdf
  214. GCC asm links:
  215. --------------
  216. official doc but quite ugly
  217. http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
  218. a bit old (note "+" is valid for input-output, even though the next disagrees)
  219. http://www.cs.virginia.edu/~clc5q/gcc-inline-asm.pdf