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 _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
