Run Time Improvement Using CBC

Q&A
,
#1

Hello everybody,

my colleague @GregorB and I are trying to improve the runtime of our oemof-model. Therefore, we want to use the parallelized version of the CBC-solver. We have installed the CBC solver with the --enable-cbc-parallel flag enabled.

We use the CBC-solver with the following command:

om.solve(solver=’cbc’, cmdline_options={“threads”:6})

Our problem now is that a higher number of threads does not lead to a reduction of computing time. Does anyone have any experience with this and can help us to reduce the computing time?

Many thanks in advance for your help!

#2

Your result is about what I would expect. Studies are occasionally published comparing the performance of various linear solvers across standard problems and on different hardware. I recall one (which I cannot place my hands on right now) that suggested that about eight cores are needed to gain any improvement in solution time. In the meanwhile, you should search the literature for these studies.

(And while I’m here, it is better to use @‑handles and not real names. @‑handles are clickable, will generate notifications under default settings, and can be automatically anonymized when someone requests “erasure” under privacy law. And we have already had one such request so this is not entirely hypothetical.)

#3

Hi cklm, as Robbie pointed out this is not very surprising.
For barrier algorithms applied on LPs, one would expect a slight model-dependent speedup with increasing number of cores used. This is mostly because some computationally expensive steps in barrier such as the Cholesky factorisation are parallelisable. However, the other steps of the algorithms are barely parallelisable, thus leading to a far-below linear speedup. . For simplex, there is almost no gain from parallelisations.
For MILPs on the other hand, the potential speedup is even larger.
If your processor uses hyper-threading, using more threads than cores could also potentially slow down the optimisation.
Some solvers such as Gurobi also offer concurrent as a solver option leading to different cores using different algorithms to receive the result from whatever algorithm finishes first.

#4

Hello @robbie.morrison and @alexkies,

first of all we want to thank you for your answers. Unfortunately we could not improve the runtime even with 8 and more threads. Now the question, if you have further ideas to improve the runtime apart from changing the solver.

Many thanks in joyful expectation of your help.

@cklm & GregorB

#5

You may ask in a pyomo or cbc forum, because the problem might not be related to oemof.

Does the solver uses 6 or 8 cores? Your parameter is passed from oemof-solph to pyomo and from pyomo to cbc. There could be a problem in this chain and the solver does not get the information.

So I would investigate on the cbc-level. With solph it is possible to create an lp file. You can execute the cbc solver directly with this lp-file and bypass pyomo and solph.

I do not have another idea to improve the solver speed but if you have parameter variations or different scenarios you could parallelize these optimisations. This will not speed up a single run but n optimisations are as fast as one, which could also help.

#6

Thanks @uwe.krien, we tested if the solver gets the information about the threads, and it does. We will now follow your advice and ask in a Pyomo or CBC forum.

#7

Solver comparison tests

Earlier in this thread I mentioned solver comparison tests. Mathematician Hans Mittelmann has, for many years, presented benchmark tests for both proprietary and open source mathematical program solvers to the INFORMS annual meetings. But circa 2019, these benchmarks no longer include the top three proprietary solvers due to commercial rivalries. As Hans recently wrote on his website (cited below):

IBM [CPLEX] and FICO [Xpress] demanded that results for their solvers be removed and then we decided to temporarily remove those of Gurobi [Gurobi] as well.

There is further background on this unfortunate dispute in Mittelmann (2019) — refer in particular to slide 30 and you will understand the source of the conflict. But Hans continues to benchmarks the common open source solvers — see his website for details.

Sources:

Text and images licensed under CC BY 4.0.  Data licensed under CC0 1.0.  Code licensed under MIT.  Site terms of service.  Openmod mailing list.