Recherche avancée

Sur d’autres sites (12205)

• swresample/resample : improve bessel function accuracy and speed

  2 novembre 2015, par Ganesh Ajjanagadde

  swresample/resample : improve bessel function accuracy and speed
  This improves accuracy for the bessel function at large arguments, and this in turn
  
  should improve the quality of the Kaiser window. It also improves the
  
  performance of the bessel function and hence build_filter by 20%.
  
  Details are given below.
  Algorithm : taken from the Boost project, who have done a detailed
  
  investigation of the accuracy of their method, as compared with e.g the
  
  GNU Scientific Library (GSL) :
  
  http://www.boost.org/doc/libs/1_52_0/libs/math/doc/sf_and_dist/html/math_toolkit/special/bessel/mbessel.html.
  
  Boost source code (also cited and licensed in the code) :
  
  https://searchcode.com/codesearch/view/14918379/.
  Accuracy : sample values may be obtained as follows. i0 denotes the old bessel code,
  
  i0_boost the approach here, and i0_real an arbitrary precision result (truncated) from Wolfram Alpha :
  
  type "bessel i0(6.0)" to reproduce. These are evaluation points that occur for
  
  the default kaiser_beta = 9.
  Some illustrations :
  
  bessel(8.0)
  
  i0      (8.000000) = 427.564115721804739678191254
  
  i0_boost(8.000000) = 427.564115721804796521610115
  
  i0_real (8.000000) = 427.564115721804785177396791
  bessel(6.0)
  
  i0      (6.000000) = 67.234406976477956163762428
  
  i0_boost(6.000000) = 67.234406976477970374617144
  
  i0_real (6.000000) = 67.234406976477975326188025
  Reason for accuracy : Main accuracy benefits come at larger bessel arguments, where the
  
  Taylor-Maclaurin method is not that good : 23+ iterations
  
  (at large arguments, since the series is about 0) can cause
  
  significant floating point error accumulation.
  Benchmarks : Obtained on x86-64, Haswell, GNU/Linux via a loop calling
  
  build_filter 1000 times :
  
  test : fate-swr-resample-dblp-44100-2626
  new :
  
  995894468 decicycles in build_filter(loop 1000),     256 runs,      0 skips
  
  1029719302 decicycles in build_filter(loop 1000),     512 runs,      0 skips
  
  984101131 decicycles in build_filter(loop 1000),    1024 runs,      0 skips
  old :
  
  1250020763 decicycles in build_filter(loop 1000),     256 runs,      0 skips
  
  1246353282 decicycles in build_filter(loop 1000),     512 runs,      0 skips
  
  1220017565 decicycles in build_filter(loop 1000),    1024 runs,      0 skips
  A further 5% may be squeezed by enabling -ftree-vectorize. However,
  
  this is a separate issue from this patch.
  Reviewed-by : Michael Niedermayer <michael@niedermayer.cc>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libswresample/resample.c

• swresample/resample : speed up Blackman Nuttall filter

  9 novembre 2015, par Ganesh Ajjanagadde

  swresample/resample : speed up Blackman Nuttall filter
  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 : Michael Niedermayer <michael@niedermayer.cc>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libswresample/resample.c

• swresample/resample : speed up upsampling by precomputing sines

  9 novembre 2015, par Ganesh Ajjanagadde

  swresample/resample : speed up upsampling by precomputing sines
  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 : Michael Niedermayer <michael@niedermayer.cc>
  
  Signed-off-by : Ganesh Ajjanagadde <gajjanagadde@gmail.com>
  

  • [DH] libswresample/resample.c