Hans Mittelmann has some new benchmarks comparing CPLEX 12.1 with GUROBI 1.1.2 on various mixed integer linear programming instances (I last wrote on these benchmarks last January with earlier versions of both codes: be sure to check out the comments from that post since many of those comments apply to this also). He covers both feasibility and optimization problems.
Checking the computation times for one set of optimizatin instances:
problem CPLEX1 GUROBI1 CPLEX4 GUROBI4 ------------------------------------------------------ bc1 101 94 81 51 bienst2 165 58 87 27 dano3_5 148 618 276 362 mark._4_0 225 45 86 36 mark._5_0 f 6909 f 4368 mkc1 5 113 5 qap10 51 76 48 73 seymour1 178 285 116 161 swath2 13 10 5 6 swath3 26 563 49 53 30_05_100 7 11 4 11
The CPLEX1 and GUROBI1 use one processor; the …4 versions use 4. The “f” means optimality was not proved in 7200 seconds (all times in seconds). The above table is not representative, so be sure to check out Hans’ page.
A couple conclusions that I come up with (your mileage may vary):
- Gurobi is a very impressive code: whether CPLEX or Gurobi will be faster on a particular instance is not predictable, which is an impressive feat.
- Parallel speedup is quite unpredictable. Often there is no, or minimal, speedup; sometimes there is huge speedup; sometimes there is a slowdown. None of this is surprising: the initial linear relaxation is hard to parallelize, and the nondeterministic nature of tree search can lead to getting “lucky” or “unlucky” in the parallel search.
If we pull a few lines from the feasibility benchmarks:
============================================================ problem CPLEX FP-ab FP-bfl SCIP GUROBI ------------------------------------------------------------ atlanta-ip 848 23 21 391 189 core4872-1529 1 413 52 374 1 ds 1 - 5350 38 3 germanrr 183 10 6 200 19 momentum1 1 23 17 6257 2 momentum2 6181 47 71 1504 4118 momentum3 1 350 627 - 4 msc98-ip 185 19 25 1754 33 neos16 47 236 241 43 72 neos-506428 1338 2969 4531 1739 2694
(FP are Feasibilty Pump approaches; SCIP is a fast non-commercial code). Here the results are all over the map: practically anything can win and anything can lose and there can be three orders of magnitude difference between running times.
Now speed is not the only thing to look for in an optimization code (support, interfaces, price are a few other things to look at), but these benchmarks are very useful in trying to compare codes. Thanks Hans!
I am interested in Cplex and I am developing myself about Cplex.Thanks for informations.Good works.