On Fri, Nov 04, 2005 at 04:49:43PM -0500, cswiger wrote: > Since AMD 64 dual core chips are getting affordable, any thoughts on if > gnuradio can take advantage of them as it is? Quoth one review, they're: > > "aimed at users who need high arithmetic performance and use mainly > multithreaded applications."
Currently if the flow graph is partitionable into two or more disjoint graphs, each subgraph runs it's own thread. Pretty much any transceiver code falls in this category. Taking advantage of more than one processor within the same subgraph will take more work, but should be doable. >From an earlier posting: The idea in the 2.x world is to dynamically partition the workload between the processors available, while taking advantage of thread/processor affinity. To give a simplified example, imagine a signal processing graph with 8 blocks in it and a dual processor system. Topologically sort the graph and assign the first 4 blocks to cpu 0, and the final 4 blocks to cpu 1. The cpus can run pretty much independently of each other with good memory and cache locality, with the proviso that there's a buffer that's shared at the boundary of the partition. cpu 0 writes into the buffer, cpu 1 reads from the buffer. Access to this buffer is of course serialized with a mutex, etc. When the producer/consumer rendezvous occurs, on the average (assuming that each block requires a relatively constant amount of cpu, memory bandwidth, etc for a particular throughput), either cpu 0 is going to be write blocked or cpu 1 is going to be read blocked. If cpu 0 is write blocked (meaning that it's getting done with its work before cpu 1 is), we can change the partitioning by migrating the fifth block from cpu 1 to to cpu 0, thereby changing the relative work loads. Assume we low-pass filter this repartitioning activity, so that we're not migrating the same block back and forth. It should settle down to a partitioning that's getting everything it can out of all cpus available while maintaining good locality and low coordination overhead. Eric _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio