On Thu, Oct 09, 2008 at 09:26:47PM +0200, Stefan Brüns wrote: > Hi, > > I ran some performance analysis of the inband code, and found the pmt based > message passing as highly inefficient. > > As a first step, I changed the pmt_list[1-6] implementations from using an > imbalanced tree with refcounted pairs against a much more simple pmt_vector > based one, resulting in a huge speedup. > > Unfortunately, this means going from ~770 instructions per sample [1] to ~300 > instructions per sample, which is still just to much. > > The high cost is due to the following reasons: > On each received sample block, the data is passed between the mblocks. For > this, messages are created, every fields refcount gets incremented, on > message reception the fields refcounts are adjusted again, and when the > receiving block finishes, the fields refcounts and the messages refcount are > decreased, leading to release of the fields and the message (as the receiving > block is normally the only block holding a reference to the message). > > Much of this work is just not necessary - I think the messages should be much > more statically typed, using refcounted objects only for large objects (e.g, > pass the sample data as refcounted object, the package length as a POD). > > Any opions on this topic? > > Stefan
I think changing the args from list to vector would be a simple win. The other problem is that mblocks currently use a thread per block, instead of using a small pool of threads to execute all the blocks. The pmt type probably needs to be reimplemented. The current version was coded in about 1 day. It was the simplest thing that could have possibly worked. I'm disinclined to go with statically typed messages for a number of reasons that I don't have time to go into now. Think about lisp, scheme, python, ruby, erlang... marshalling self-describing data across a network connection... It is possible to have types like these with very good performance. See SBCL or any other high-performance lisp system for a concrete example. There's over 40 years of literature and corresponding high-performance systems in this area. Eric _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
