Recherche avancée

Sur d’autres sites (7100)

• lavc/pcm_tablegen : slight speedup of table generation

  31 décembre 2015, par Ganesh Ajjanagadde

  lavc/pcm_tablegen : slight speedup of table generation
  This gets rid of some branches to speed up table generation slightly
  
  (impact higher on mulaw than alaw). Tables are identical to before,
  
  tested with FATE.
  Sample benchmark (Haswell, GNU/Linux+gcc) :
  
  old :
  
   313494 decicycles in build_alaw_table,    4094 runs,      2 skips
  
   315959 decicycles in build_alaw_table,    8190 runs,      2 skips
   323599 decicycles in build_ulaw_table,    4095 runs,      1 skips
  
   318849 decicycles in build_ulaw_table,    8188 runs,      4 skips
  new :
  
   261902 decicycles in build_alaw_table,    4096 runs,      0 skips
  
   266519 decicycles in build_alaw_table,    8192 runs,      0 skips
   209657 decicycles in build_ulaw_table,    4096 runs,      0 skips
  
   232656 decicycles in build_ulaw_table,    8192 runs,      0 skips
  Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libavcodec/pcm_tablegen.h

• lavc/dsd_tablegen : speed up table generation

  29 décembre 2015, par Ganesh Ajjanagadde

  lavc/dsd_tablegen : speed up table generation
  Tables are bit identical.
  
  Sample benchmark (Haswell, GNU/Linux+gcc) :
  
  old :
  
   814485 decicycles in dsd_ctables_tableinit,     512 runs,      0 skips
  new :
  
   356808 decicycles in dsd_ctable_tableinit,     512 runs,      0 skips
  Binary size should essentially be identical, and is in fact identical on
  
  the configuration I tested on.
  Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libavcodec/dsd_tablegen.h

• lavu/libm : add erf hack and make dynaudnorm available everywhere

  20 décembre 2015, par Ganesh Ajjanagadde

  lavu/libm : add erf hack and make dynaudnorm available everywhere
  Source code is from Boost :
  
  http://www.boost.org/doc/libs/1_46_1/boost/math/special_functions/erf.hpp
  
  with appropriate modifications for FFmpeg.
  Tested on interval -6 to 6 (beyond which it saturates), NAN, INFINITY
  
  under -fsanitize=undefined on clang to test for possible undefined behavior.
  This function turns out to actually be essentially as accurate and faster than the
  
  libm (GNU/BSD’s/Mac OS X), and I can think of 3 reasons why upstream
  
  does not use this :
  
  1. They are not aware of it.
  
  2. They are concerned about licensing - this applies especially to GNU
  
  libm.
  
  3. They do not know and/or appreciate the benefits of rational
  
  approximations over polynomial approximations. Boost uses them to great
  
  effect, see e.g swr/resample for bessel derived from them, which is also
  
  similarly superior to libm variants.
  First, performance.
  
  sample benchmark (clang -O3, Haswell, GNU/Linux) :
  3e8 values evenly spaced from 0 to 6
  
  time (libm) :
  
  ./test  13.39s user 0.00s system 100% cpu 13.376 total
  
  time (boost based) :
  
  ./test  9.20s user 0.00s system 100% cpu 9.190 total
  Second, accuracy.
  
  1e8 eval pts from 0 to 6
  
  maxdiff (absolute) : 2.2204460492503131e-16
  
  occuring at point where libm erf is correctly rounded, this is not.
  Illustration of superior rounding of this function :
  
  arg : 0.83999999999999997
  
  erf : 0.76514271145499457
  
  boost : 0.76514271145499446
  
  real : 0.76514271145499446
  i.e libm is actually incorrectly rounded. Note that this is clear from :
  
  https://github.com/JuliaLang/openlibm/blob/master/src/s_erf.c (the Sun
  
  implementation used by both BSD and GNU libm’s), where only 1 ulp is
  
  guaranteed.
  Reasons it is not easy/worthwhile to create a "correctly rounded"
  
  variant of this function (i.e 0.5ulp) :
  
  1. Upstream libm’s don’t do it anyway, so we can’t guarantee this unless
  
  we force this implementation on all platforms. This is not easy, as the
  
  linker would complain unless measures are taken.
  
  2. Nothing in FFmpeg cares or can care about such things, due to the
  
  above and FFmpeg’s nature.
  
  3. Creating a correctly rounded function will in practice need some use of long
  
  double/fma. long double, although C89/C90, unfortunately has problems on
  
  ppc. This needs fixing of toolchain flags/configure. In any case this
  
  will be slower for miniscule gain.
  Reviewed-by : James Almer <jamrial@gmail.com>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] configure
  • [DH] libavutil/libm.h