Re: [Discuss-gnuradio] First integration (was: Re: Run graph/ scheduler overhead)

[Richard Bell]

This topic of hardware efficient designs vs general purpose processor (GPP) 
efficient is very interesting. I assumed the most efficient hardware designs 
would tend to translate well into a GPP, because most good hardware designs are 
good because they parallelize things like crazy. You would think that would 
payoff in a GPP as well, up to the number of cores available. After reading 
this and Toms blog on FFT filters vs FIR filters vs Polyphase filters, it seems 
not to be the case in a lot of situations. My basic intuition makes me think 
now that the GPP is very similar to a serial process when compared to an FPGA. 
For this reason it is worth focusing a lot of energy on efficient serial 
designs and not as much on massively parallel ones. 

Is there literature on what metrics matter most when designing algorithms for a 
GPP vs an FPGA, or is it mostly something you learn through experience? The GPP 
has so many variables that come along with it that I imagine it's hard to do 
much other then implement and test. Fun to think about. 

Rich

Sent from my iPad

> On Jul 24, 2015, at 10:51 PM, Dennis Glatting <address@hidden> wrote:
> 
> 
> 
>> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio