Thanks. Yes, my block has internal data-feedback [using signal processing block output to calculate new FIR filter coefficients, a trait common in adaptive filters]. It runs with 1 FIR Filter pretty quickly with 1 core no problem, but once I start pushing it to 5 and up, my computer can't keep up. At around 2 or 3 the core working on it is really stressed.
I did notice that when I run example flow graphs or when I create flow graphs that doesn't have any of my custom algorithms, it does really well dividing the tasks to separate cores. Could you point a reference to this topic please? I tried googling "internal data feedback" and "data-flow feedback" with words like parallel, c++, and I'm not getting good results. Thanks. On Mon, Jan 10, 2011 at 3:45 PM, Michael Dickens <m...@alum.mit.edu> wrote: > Without seeing your GRC implementation or Python script & block's > implementation code, mostly what I or anyone else can provide is general > advice. GNU Radio 3.3.0 uses the thread per block (TBP) scheduler by > default; if you're not doing anything else except running the flow-graph > (meaning: you don't set special GNU Radio environment variables or use a GNU > Radio configuration file), then that's what you're using. The performance > of any flow-graph really depends on how complex the flow-graph is, how much > data you're trying to push through it, and how fast your processors are able > to perform the block's computations. The host OS influences execution speed > a little, but mostly its those listed factors that make the difference; that > said, I haven't used GNU Radio on Ubuntu in a long time so I cannot talk > about that OS specifically (Linux, in general, provides very low OS overhead > & more time executing the flow-graph's computations). It might be that your > flow-graph is running fast enough already to use just 1 core; does it run in > "real time" for what you need? Rewriting a given block to use vector-based > instructions (SSE, Altivec, Neon) often dramatically increases the > computations / time for that block. As for parallelizing your block, > without knowing what it is/does exactly, I would always advise you to break > down the computations into smaller pieces and then implement those as blocks > (if they are no already), then create the "meta-block" (I forget the exact > name of it now; maybe "heir_block2"?) using those. That way, the TBP > scheduler will have more to work with and the flow-graph will end up being > executed more in parallel. If your block has internal data-feedback, then > the meta-block will not work (GNU Radio doesn't "do" data-flow feedback in > the flow-graph) & you'll have to find some way of parallelizing your > algorithm. There are plenty of good books on this subject. - MLD > > On Jan 10, 2011, at 3:11 PM, sirjanselot wrote: > > I am currently using gnuradio 3.3.0 as my version. > > How do I know that my flow-graph is executing in thread per block mode? > > > > As far as I can tell my only 1 core out of the 8 is being used when I run > my > > flow-graphs. This is what I see when I run the performance monitor (or > > whatever it is called) in Ubuntu. > > > > So can I parallelize my block without having to create a meta-block as > you > > say? I have a lot of for-loops and vector calculations that need to be > > optimized (adaptive fir filters). >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
