Re: [Discuss-gnuradio] Inefficiency of message passing in inband code

[Eric Blossom]

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