Re: [Discuss-gnuradio] Comparison of filters in C++ vs Python

[Eric Blossom]

On Fri, Sep 15, 2006 at 01:45:02PM -0600, Jim Borynec wrote:
> Sorry, it could be my misunderstanding of Gnuradio.

Yes.

> As I understand it, the basic metaphor of Gnuradio is a graph with vertexes 
> and edges.
> Each vertex is a component (some of which are in C++, others in Python.
> You connect the vertexes with edges defined in the whatever main python 
> program.
> and turn it "on".  Each vertex is essentially a state machine,
> taking in inputs, doing computations and handing over outputs to the next 
> machine.

The graph is "flattened" such that all that's left at runtime is C++ code.

> My question relates to the performance of this architecture.
> 
> How much overhead is associated with the "machine" as opposed to the actual 
> work.

Since there's no Python involved in the runtime, that overhead is 0%.
The overhead spent dynamically scheduling the blocks in the graph is on
the order of  5%.

> Let us take a look at simple filters as an example.
> One filter will multiply an input stream to get a gain on the signal.
> Another filter will add a constant to an input stream to translate it's 
> position.
> 
> We can string these two filters in a row to do a translate and amplify 
> filter.
> 
> However, we might already have a single filter which already does a 
> translate and amplify function.
> 
> So my question is, how much less efficient is stringing the two filters in 
> a row compared with using the combined filter.

Generally speaking, we've found little need to consolidate multiple
blocks into single blocks.  There is of course always that
possibility.  The general guideline is "premature optimization is the
root of all evil".  If AFTER MEASURING it appears that it will make a
significant difference in your application, then it might make sense
to merge a block or two.

> The larger motivation here is to understand the trade off between simply 
> gluing existing filters together versus writing my own custom filter.

Do you value your own time?
What does a fast computer cost?

Although we include blocks that do trival operations such as "add a
constant", the bulk of them provide higher level functions, e.g.
"evaluate this FIR filter".  Many of those that have been shown to be
a substantial bottleneck have been reimplemented in hand-coded SIMD
assembler.


> Also, what are the tradeoffs between python and C++.

Python is a breeze to work in.  Very high level, automatic storage
management, nice object system, first class functions, great
libraries, easy to interface to external libraries, but on the slow
side for number crunching.

Compared to Python, coding in C++ is a pain in the ass and leaves you
dealing with low level details.  No automatic storage management, no
lexical closures, no higher-order functions, ...  Cetainly for some
situations C++ is faster, particularly tight loops that don't map into
one of the Python primitives.

Generally speaking, I prefer to write in Python unless there's a
compelling reason not to.

> Do these questions make sense?

Yes, thanks.
Hope this helped.

Eric