Generally, you shouldn't need to further parallelize beyond what's already provided. A specific case where one would want do add another thread is when data must be transferred non-synchronously (e.g., async or isync) -- for example, the native USB driver for Mac OS X spawns a new thread to handle the OS-interface part. Otherwise, you can probably find a clever way to create a "meta-block" that encloses a number of actual blocks, and then let the "thread per block" scheduler handle them. GNU Radio uses Intel's TBB already, so if you feel for some reason that your particular block(s) need more parallelization, then that's probably the best way to go.
My US$0.02, for what it's worth. - MLD
On Jan 10, 2011, at 10:52 AM, sirjanselot wrote:
> I've been writing my own signal processing blocks and I noticed that
> gnuradio only uses one of my cores.
>
> I'm not sure if it is using just one core for my blocks or for all
> processing.
>
> Is gnuradio written to take advantage of multicore processing?
>
> I have been writing my blocks in generic c++ code, but now I am looking to
> write my blocks using multithreading/multicore processing. However, I am
> new to this and would like some advice on how to approach this.
>
> I have an Intel 8-Core Xenon in my PC (I don't know the exact model but I
> believe the clock rate works around 2.8 Ghz). What libraries should I use?
> I have been looking into Intel Thread Building Blocks, but I am wondering
> what people mainly use for gnuradio.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment