Re: [boost] [threadpool] parallel_sort example

Subject: Re: [boost] [threadpool] parallel_sort example
From: Edouard A. (edouard_at_[hidden])
Date: 2009-03-01 18:06:25

let me think that the application should not create ThreadPools
> for specific algorithms, but use a default one.
> The V21 of Boost.ThreadPool provide a
> boost::this_task::get_thread_pool<pool_type>(), but this function works
> only if called from a task. It should be great if the Boost.ThreadPool
> provided a default pool which could be recovered with this function on
> threads that are not worker threads of a ThreadPool. Otherwise the
> application is forced eother to add a parameter to all the functions or
> define its own default thread pool statically.

[Edouard A.] 

First of all don't be disappointed by the performance gain, while it is true
that you can hope for almost 100% performance gain on a dual core CPU, there
are a lot of parameters to consider (including the CPU itself, what is the
specific CPU you are using?).

I also think that having a default pool is a must. What you can do is have a
boost::tp:get_default_pool() that would be using Meiers idiom for
singleton's (i.e. having the function returning a static local variable). 

You should also compare your results with Intel TBB parallel_sort and use
containers designed for multithreading operation (especially true for
vectors). If TBB offers similar performance gain then maybe the problem is
your CPU.

Also test on random data: std::generate(values1.begin(), values1.end(),
&rand);

For your information I worked a little bit on a parallel implementation that
didn't use any task scheduling, performances was 20% below TBB. Using
quicksort or merge sort offered similar performances. With your strategy you
should be between these 20% and TBB (perhaps you can outperform TBB!).

The overhead of scheduling is compensated by the fact that the load is
equally distributed amongst the cores. This is the conclusion of my tests on
a Q6600 under Vista-64.

Regards.

-- 
Edouard