GNU Radio multicore support

GNU Radio
1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Old documentation on GNU radio says that it would have transparent
SMP/multicore/SMT support for signal processing by version 2.x; on 20
March 2007 Marcus L. sent an email claiming

“”"
Eventually, Gnu Radio will support multi-threading for processing blocks
that are particularly expensive, I think, which will be much more useful
on multi-core CPUs. Currently I think only the signal processing and
Gui chains are in different threads.
“”"

Is this still true (I certainly don’t see SMP use on my two multicore
machines), and if so what has prevented this from happening?

Thanks,

  • -Dan
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (GNU/Linux)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG6u/hy9GYuuMoUJ4RArs/AKCgUY/HUdnqWDIdOnjMMylryGzscACfVN3a
o+NjcO7eRoeIkk9DhxqdaUE=
=lzkn
-----END PGP SIGNATURE-----

2

On Fri, Sep 14, 2007 at 01:32:33PM -0700, Dan H. wrote:

Gui chains are in different threads.
“”"

Is this still true (I certainly don’t see SMP use on my two multicore
machines), and if so what has prevented this from happening?

FWIW, currently disjoint subgraphs are each run in their own thread.

As part of the work I’m doing for the Cell processor, we’ll have a
“thread-per-block” scheduler that will take advantage of SMP/SMT
resources. We may end up implementing some kind of “work stealing”
technique (c.f. Cilk), where we really run N on M, where M is
f(actual-hw-resources). A naive “thread-per-block” scheduler
implemented for mblocks has so far turned out to be too heavy-weight
for production use. The situation may be different with gr_blocks,
since they may burn more cycles (on avg) in their work methods than
the mblocks do.

Eric

3

But why would this be true if you were to use a thread pool?

Bob

Eric B. wrote:

on multi-core CPUs. Currently I think only the signal processing and
resources. We may end up implementing some kind of “work stealing”
technique (c.f. Cilk), where we really run N on M, where M is
f(actual-hw-resources). A naive “thread-per-block” scheduler
implemented for mblocks has so far turned out to be too heavy-weight
for production use. The situation may be different with gr_blocks,
since they may burn more cycles (on avg) in their work methods than
the mblocks do.

Eric

–
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
“If you’re going to be crazy, you have to get paid for it or
else you’re going to be locked up.” Hunter S. Thompson