[Cbc] Parallel Cbc: adding threads fails to improve performance

[Stefan Vigerske]

Hi,

a year ago, in the old times of Cbc 2.1, it seemed to decrease wall
clock time when using two instead of one thread.
For example, with misc07 I observed a decrease from 89.65 to 63.14 seconds.
See also http://www.coin-or.org/GAMSlinks/benchmarks/MIP/cbc_080719
for the complete benchmark.
I haven't tried such a comparision with a recent Cbc yet.

Stefan

acw at ascent.com wrote:
> We have a Cbc application that has been doing quite well for us, but as we 
> foray into more and more complicated problems we are always interested in 
> improving performance.  So we were pleased to learn that parallelization 
> had been added to Cbc, and we decided to test it out.
> 
> For this test we built Cbc  with the --enable-cbc-parallel-flag on a 
> quad-core Linux box, and used the bin/cbc executable.  We downloaded a few 
> test problems from MIPLIB2003 from the archive site miplib.zib.de.  We ran 
> these problems with different values of the -threads parameter, and were 
> surprised to discover that adding threads did not improve performance; 
> instead, performance was almost unchanged for one problem (miu.mps), and 
> degraded slightly with additional threads for some others (aflow30a.mps, 
> aflow40b.mps, misc07.mps).
> 
> We used the following command structure:
> 
> cbc -threads <n> -import <mps file> -solve
> 
> We varied n from 0 (though we don't know what 0 means!) through 5 (even 
> though we didn't have five cores!), and never saw a case where increasing 
> n improved performance more than marginally, and many cases where it hurt.
> 
> We must be doing it wrong.  Is anyone else having success improving 
> performance with parallelized Cbc?
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Cbc mailing list
> Cbc at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/cbc