[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Making the fractional resampler faster

From: Eugene Grayver
Subject: [Discuss-gnuradio] Making the fractional resampler faster
Date: Thu, 13 Jun 2019 00:43:18 +0000

The fractional resampler is frequently the most computationally expensive block in a transmitter (and even in a receiver).  It is also notoriously difficult to parallelize.    GR comes with a few options for non-integer resampling: polyphase, mmse, rational.  I benchmarked all of them on a variety of machine for a rate change of 1.023.  Turns out the old fractional_resampler is a bit faster than the polyphase.   However, it was still too slow (could not keep up at ~30 Msps).


A one-line change to the fractional_resampler_[cc/ff] increases throughput by almost 3x.  The current fractional resampler uses the basic filter kernel.  The filter kernel is really pretty clever – uses SIMD via VOLK and goes to great lengths to keep everything aligned on cache boundaries.  All that overhead is worth it when the filter has lots of taps.  However, the resampler filter is exactly 8 taps.  The overhead of calling into the filter kernel is much, much larger than the work done in the kernel.


Simply replace the line:


          out[oo] = d_resamp->interpolate(&in[ii], d_mu);



      auto TAPS = taps[(int) d_mu];

       out[oo] = in[ii+0] * TAPS[7] + in [ii+1] * TAPS[6] + … in [ii+7] * TAPS[0].


taps come from ‘interpolator_taps.h’


I wish I could just post the diff myself, but company policy does not allow me to.


Instant speedup of 2.5X (complex), 3X (real).  It may be even faster if we used a SIMD intrinsic, but compilers are really pretty good at optimizing these days!



In the immortal words of Donald Knuth: Premature optimization is the root of all evil.



Eugene Grayver, Ph.D.

Principal Engineer
Digital Communications Implementation Division
(310) 336-1274


reply via email to

[Prev in Thread] Current Thread [Next in Thread]