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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
