CODEWITHSUNDEEP
c++signal-processinggnuradio
Brad Hein
Brad Hein

Reputation: 11057

Gnuradio C++ block: high CPU

I've created a python Gnuradio block, and now I'm re-coding it in C++. What I noticed is something very unexpected - the C++ block (python flowgraph process) consumes more CPU (~125%) than the Python version (18%) that does the same thing. I must be doing something wrong... so -

I created a new block with no custom code other than setting the variable type to float, and number of inputs and outputs to 1, and I see the same behavior. I must be doing something wrong but I can't tell what... 

$ gnuradio-config-info -v
3.7.11

Platform: Mac / x86_64

Here's how I created the block within my existing module: 

$ gr_modtool add -t general donothingcpp
GNU Radio module name identified: acsound
Language (python/cpp): cpp
Language: C++
Block/code identifier: donothingcpp
Enter valid argument list, including default arguments: 
Add Python QA code? [Y/n] n
Add C++ QA code? [Y/n] n
Adding file 'lib/donothingcpp_impl.h'...
Adding file 'lib/donothingcpp_impl.cc'...
Adding file 'include/acsound/donothingcpp.h'...
Editing swig/acsound_swig.i...
Adding file 'grc/acsound_donothingcpp.xml'...
Editing grc/CMakeLists.txt...

Here's the flow-graph used for testing: gnuradio flow graph

I modified the constructor to specify one input and one output and then I tweaked the variable type in the general_work function, which now looks like this: 

int
donothingcpp_impl::general_work (int noutput_items,
                   gr_vector_int &ninput_items,
                   gr_vector_const_void_star &input_items,
                   gr_vector_void_star &output_items)
{
  const float *in = (const float *) input_items[0];
  float *out = (float *) output_items[0];

  // Do <+signal processing+>
  // Tell runtime system how many input items we consumed on
  // each input stream.
  consume_each (noutput_items);

  // Tell runtime system how many output items we produced.
  return noutput_items;
}

Whether I do any work in the general_work function or not, the CPU consumption for that process runs at about 125%. Of course with each code change I make clean, make, and make install to get the block into gnuradio. If I add debug messages I see them on the console so I know my code changes are being seen and used when I run the flowgraph.

If I bypass the donothing block and run the flowgraph, it consumes 0.3% CPU.

I tried both null and probe signal sinks but neither seem to be a factor.

I'm at a loss however for explaining the high CPU consumption when I run custom C++ blocks.

Upvotes: 1

Views: 1134

Answers (1)

Marcus M&#252;ller
Marcus M&#252;ller

Reputation: 36442

You're consuming the number of output samples, but that's wrong in the general case (it's correct in the sync block case, where the number of output items is always identical to the number of consumed input items).

Now, since your block doesn't check whether there's enough input items, it's always asked to run – hence, the burning of CPU.

I feel like you "accidentally" made a general block (with a general_work), but meant to make a sync block (with a work).

Upvotes: 1

Related Questions