Re: [boost] [threadpool] version 22 with default pool

Subject: Re: [boost] [threadpool] version 22 with default pool
From: Edouard A. (edouard_at_[hidden])
Date: 2009-03-09 17:13:13

> > I also increased the size of the block to 10,000 and performance
> improved a
> > little bit (to ~ 0.316). If I increase to 100,000, performance go
> back to ~
> > 0.331.
> 
> Good new, isn't it?

Yes, but there is room for improvement... As long as we don't go four times
faster than std::sort, we can do better. ;)

> > I've run a test with sizes between 100 and 150,000 and it seems to
> have
> > little impact on the outcome. This is strange. It's a bit early to
> say if
> > it's bad news. See csv & graph attached. I've used GetTickCount to
> measure.
> 
> I agree this is suspect.
> 
> > We should perhaps do a test where we would inject large amount of
> tasks of
> > precise duration and see how the scheduler behaves. It would also be
> > interesting to measure the delay of execution of one of the tasks (if
> you
> > know a task should last 1 s, measure how long it actually took).
> 
> Profiling will be welcome.

The latency + bandwidth test should explain why the slice's size doesn't
seem to affect the performances. For the test task I see something like:

for(int count = ::GetTickCount(); count != target; count  =
::GetTickCount());

This is a trivial spin to make sure the tasks eat up some CPU for the
desired amount of ms.

-- 
EA