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

Rafael.Lopez at lri.fr Rafael.Lopez at lri.fr
Sat Jun 6 03:44:36 EDT 2009


> 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?

What measure of performance did you use? I remember doing some tests with
parallel Cbc and getting counter-intuitive values from the reported time,
for example:

One thread, Cbc reports 200 seconds used to solve and did take 200s or so
Two threads, Cbc reports 250 seconds used to solve but actually took 130s
or so.
Just reading Cbc's report, one could think two threads (on a dual-core)
performed worse that single thread, but in fact, when you measure the
actual time elapsed, there was a significant improvement. The discrepancy
comes from each thread counting its own time spent, and Cbc reporting the
sum of both at the end.
The other thing I think happens is that when using multple threads, Cbc
will explore more solution space than what a single thread would do, which
is why each paralell thread takes more than half/a third/fourth of the
time a single thread would take.


> _______________________________________________
> Cbc mailing list
> Cbc at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/cbc
>




More information about the Cbc mailing list