discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] performance improvements and using volk


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] performance improvements and using volk
Date: Thu, 10 Nov 2011 11:35:01 -0500

On Wed, Nov 9, 2011 at 5:25 PM, Josh Blum <address@hidden> wrote:
I just added a gr_basic_add_const and gr_basic_multiply_const. Nick
added the volk (and orc) implementations for the float32 and complex
float32 implementations of the multiplier.

>
> So I like everything about this but the name.  We could stuff all of this
> under the "gnuradio.gr" namespace in Python, or we could name this
> "gr-math."
>
> Actually, while I was typing this, I'm thinking we rename the directory to
> be "gr-blocks" but put them under the "gnuradio.gr" namespace. I'm


Trying to avoid math so from gnuradio import math doesnt interfere with
python's math import. Thats unfortunate, but I think this will be nicer
with the python namespace changes you mentioned.

#example import:
from gnuradio import gr
gr.filter.fir_interp(...)
gr.math.add(...)
gr.digital.costas_loop(...)

Was that the goal? I think we can make this happen without too much trouble

Yeah, this should be easy. But I think most people are pretty used to "from gnuradio import something", so you're right about the potential problems of a collision between gr.math and math.

The goal? To allow for easy development and control over properly segmented groups of blocks without driving the users crazy by constantly changing or adding new groups. That's one reason why I think stuffing everything in your gr-basic into the gr namespace, so people would still have the familiar "from gnuradio import gr" way of getting to most of the core blocks.

> expecting that since you've used different names for the blocks because of
> the data-type handling that they won't collide with what's in guradio-core
> right now.
>

So, my thoughts were: make new blocks that replicate the functionality
in gr-core like filters, adders, etc. We dont delete the old blocks, so
the API doesn't change. But if you want the performance improvement, you
use the new blocks.

Agreed. Eventually, we'd want to get rid of the old blocks (reduce cruft, etc). Of course, that'd be a _huge_ api change since these are blocks used frequently for many tasks.
 
Hopefully with these new blocks, we use volk where applicable, use new
naming convention to make it easier to fit alternative data types, and
avoid generation when possible.

No disagreement there.
 
Eventually, gnuradio-core becomes nothing but the block framework and
runtime. gr-filter takes the filter implementations and gr-<???> takes
the very basic blocks like simple math operators, type conversions, and
stream conversions.

Hows that sound?

-Josh

I'd say that gnuradio-core would also contain a few blocks that are really only used for development/testing purposes (gr_nop, gr_annotator, etc.). But I otherwise agree.

I'm still advocating for gr-basic to become gr-blocks as the place for all of the generic blocks to go into, but they would be installed in gr.

Tom


reply via email to

[Prev in Thread] Current Thread [Next in Thread]