> If you can put together a patch that gives us a bit of a boost here, > that'd be great. But as you say, it doesn't look like this algorithm > as it is will ever be fantastically fast. It was definitely meant more > for hardware than this case. >
My first attempt at integration sees a performance improvement from 1.6ms to <510us (roughly -68%) according gr-ctrlport-monitor (i.e., "avg work time"). For this attempt I integrated the templates where the existing class is merely a wrapper (header and code body example below) thereby keeping the flavor of the original class interfaces, not to mention a certain amount of laziness on my part. Integrated but not tested is float. At least for the gr_complex case, my application shows squiggles on the QT GUI Sink. Oh, this is NOT C++11. Header: namespace gr { namespace filter { class FILTER_API dc_blocker_cc_impl : public dc_blocker_cc { private: dc_blocker_t<gr_complex> d_the_real_me; public: dc_blocker_cc_impl(int D, bool long_form); ~dc_blocker_cc_impl(); int group_delay(); int work(int noutput_items, gr_vector_const_void_star &input_items, gr_vector_void_star &output_items); };.75 } /* namespace filter */ } /* namespace gr */ Code body: dc_blocker_cc_impl::dc_blocker_cc_impl( int D, bool long_form ) : sync_block( "dc_blocker_cc", io_signature::make (1, 1, sizeof(gr_complex)), io_signature::make (1, 1, sizeof(gr_complex))), d_the_real_me( D, long_form ) { } dc_blocker_cc_impl::~dc_blocker_cc_impl() {} int dc_blocker_cc_impl::group_delay() { return d_the_real_me.group_delay(); } int dc_blocker_cc_impl::work( int noutput_items, gr_vector_const_void_star& input_items, gr_vector_void_star& output_items) { return d_the_real_me.work( noutput_items, input_items, output_items ); } _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio