Comparison of filters in C++ vs Python

GNU Radio
1

Hi,

Has anyone determined the basic overhead of a filter?
I can’t help but feel that stringing two filters in a row
(e.g. one to add a value and the other to multiply something)
would be less efficient than a single filter which does both operations
internally.

Does the overhead of a filter basically swamp the computation involved?

I understand the advantages of being able to quickly assemble a
complicated filter from simpler filters.

Also, has anyone quantified the cost advantage to using C++ (as compared
to Python).

Is a single Python filter (which does an add and a multiply internally)
more
efficient than two C++ filters strung together?

j.b.

2

Sorry, it could be my misunderstanding of Gnuradio.

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.

My question relates to the performance of this architecture.

How much overhead is associated with the “machine” as opposed to the
actual work.

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.

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

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

Do these questions make sense?

j.b.

3

On Fri, Sep 15, 2006 at 10:29:36AM -0600, Jim Borynec wrote:

I understand the advantages of being able to quickly assemble a complicated
filter from simpler filters.

Also, has anyone quantified the cost advantage to using C++ (as compared to
Python).

Is a single Python filter (which does an add and a multiply internally) more
efficient than two C++ filters strung together?

j.b.

Hi Jim,

I’m not sure that I’m following these questions.
The computationally expensive part of GNU Radio is coded in C++.
Python is used to glue it all together, but is generally out of the
performance critical path.

Eric

4

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%.

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