1. 10 Nov, 2015 38 commits
  2. 09 Nov, 2015 2 commits
    • Ganesh Ajjanagadde's avatar
      swresample/resample: speed up Blackman Nuttall filter · cf491a92
      Ganesh Ajjanagadde authored
      This may be a slightly surprising optimization, but is actually based on
      an understanding of how math libraries compute trigonometric functions.
      Explanation is given here so that future development uses libm more effectively
      across the codebase.
      
      All libm's essentially compute transcendental functions via some kind of
      polynomial approximation, be it Taylor-Maclaurin or Chebyshev.
      Correction terms are added via polynomial correction factors when needed
      to squeeze out the last bits of accuracy. Lookup tables are also
      inserted strategically.
      
      In the case of trigonometric functions, periodicity is exploited via
      first doing a range reduction to an interval around zero, and then using
      some polynomial approximation.
      
      This range reduction is the most natural way of doing things - else one
      would need polynomials for ranges in different periods which makes no
      sense whatsoever.
      
      To avoid the need for the range reduction, it is helpful to feed in
      arguments as close to the origin as possible for the trigonometric
      functions. In fact, this also makes sense from an accuracy point of view:
      IEEE floating point has far more resolution for small numbers than big ones.
      
      This patch does this for the Blackman-Nuttall filter, and yields a
      non-negligible speedup.
      
      Sample benchmark (x86-64, Haswell, GNU/Linux)
      test: fate-swr-resample-dblp-2626-44100
      old:
      18893514 decicycles in build_filter (loop 1000),     256 runs,      0 skips
      18599863 decicycles in build_filter (loop 1000),     512 runs,      0 skips
      18445574 decicycles in build_filter (loop 1000),    1000 runs,     24 skips
      
      new:
      16290697 decicycles in build_filter (loop 1000),     256 runs,      0 skips
      16267172 decicycles in build_filter (loop 1000),     512 runs,      0 skips
      16251105 decicycles in build_filter (loop 1000),    1000 runs,     24 skips
      Reviewed-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      Signed-off-by: 's avatarGanesh Ajjanagadde <gajjanagadde@gmail.com>
      cf491a92
    • Ganesh Ajjanagadde's avatar
      swresample/resample: speed up upsampling by precomputing sines · b87ca4bf
      Ganesh Ajjanagadde authored
      When upsampling, factor is set to 1 and sines need to be evaluated only
      once for each phase, and the complexity should not depend on the number
      of filter taps. This does the desired precomputation, yielding
      significant speedups. Hard guarantees on the gain are not possible, but gains
      themselves are obvious and are illustrated below.
      
      Sample benchmark (x86-64, Haswell, GNU/Linux)
      test: fate-swr-resample-dblp-2626-44100
      old:
      29161085 decicycles in build_filter (loop 1000),     256 runs,      0 skips
      28821467 decicycles in build_filter (loop 1000),     512 runs,      0 skips
      28668201 decicycles in build_filter (loop 1000),    1000 runs,     24 skips
      
      new:
      14351936 decicycles in build_filter (loop 1000),     256 runs,      0 skips
      14306652 decicycles in build_filter (loop 1000),     512 runs,      0 skips
      14299923 decicycles in build_filter (loop 1000),    1000 runs,     24 skips
      
      Note that this does not statically allocate the sin lookup table. This
      may be done for the default 1024 phases, yielding a 512*8 = 4kB array
      which should be small enough.
      This should yield a small improvement. Nevertheless, this is separate from
      this patch, is more ambiguous due to the binary increase, and requires a
      lut to be generated offline.
      Reviewed-by: 's avatarMichael Niedermayer <michael@niedermayer.cc>
      Signed-off-by: 's avatarGanesh Ajjanagadde <gajjanagadde@gmail.com>
      b87ca4bf