Re: [Discuss-gnuradio] oprofile inband code results

[Eric Blossom]

On Tue, Oct 09, 2007 at 11:32:52PM -0400, George Nychis wrote:
> 
> Eric Blossom wrote:
> >Because we use a lot of them to construct argument lists.  
> >It would be possible to move to an pmt_vector based approach, which
> >would cut this down dramatically.  I think we're still a bit early in
> >the game to start that kind of modification.
> >
> >I think the first thing I would try is moving to the intrusive
> >implementation of the boost shared pointers for the pmt types.
> >Then I'd look at a data type specific alloc/free as well as see how
> >the default allocator is working across multiple threads.  That is,
> >does it already use a separate allocation pool / thread.  If it
> >doesn't, we could speed up the allocation/free and reduce the amount
> >of locking required in the typical case.
> >
> >Before hacking away, I think we need to run the same test cases on
> >other machines besides the P4 Xeon and gather the oprofile data, as
> >well as the basic [ $ time <mytest> ] numbers.  We may find wildy
> >different answers as f(microarchitecture). There's a reason intel
> >isn't featuring the P4 Xeon anymore ;)
> >
> 
> This sounds good to me.  I can contribute numbers for the core duo, 
> which is my x60s laptop.  Other than that, I think I only have access to 
> P4's.  Let me organize this in terms of which applications to run for 
> the testing, write up a little how-to for running the tests, and maybe 
> others on the list can contribute results with different architectures.

Very good.

Eric