Gurobi 的速度比 CBC 求解器（使用 PuLP）慢？
Gurobi has a slower speed than CBC solver (using PuLP)?
我在 python 3.7 中使用 PuLP 设置了一个混合整数编程问题。
使用默认求解器 CBC，我的代码需要 3.9s。我想缩短时间以便加快速度，我去获得了 Gurobi 的学术许可证。
然而，当我使用它作为求解器时，它在 运行 时间上增加了将近一整秒：4.7s，与我希望的完全相反！
我通过 adding/updating 将这些行更新到设置中以使用 Gurobi 求解器（我认为这是正确的，因为它给出了相同的结果）：
solver = pl.GUROBI_CMD()
prob.solve(solver)
有谁知道速度慢的原因是什么？如果我想使用 gurobi，是否应该使用比 PuLP 更快的替代品来进行设置？
编辑：
这是日志文件：
- 加拿大广播公司
At line 2 NAME MODEL
At line 3 ROWS
At line 2301 COLUMNS
At line 219058 RHS
At line 221355 BOUNDS
At line 222359 ENDATA
Problem MODEL has 2296 rows, 2051 columns and 212512 elements
Coin0008I MODEL read with 0 errors
Continuous objective value is 0 - 0.03 seconds
Cgl0004I processed model has 1765 rows, 1704 columns (852 integer (852 of which binary)) and 54646 elements
Cbc0038I Initial state - 0 integers unsatisfied sum - 0
Cbc0038I Solution found of 0
Cbc0038I Relaxing continuous gives 0
Cbc0038I Before mini branch and bound, 852 integers at bound fixed and 852 continuous
Cbc0038I Mini branch and bound did not improve solution (0.14 seconds)
Cbc0038I After 0.14 seconds - Feasibility pump exiting with objective of 0 - took 0.01 seconds
Cbc0012I Integer solution of 0 found by feasibility pump after 0 iterations and 0 nodes (0.15 seconds)
Cbc0001I Search completed - best objective 0, took 0 iterations and 0 nodes (0.15 seconds)
Cbc0035I Maximum depth 0, 0 variables fixed on reduced cost
Cuts at root node changed objective from 0 to 0
Probing was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
Gomory was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
Knapsack was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
Clique was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
MixedIntegerRounding2 was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
FlowCover was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
TwoMirCuts was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
Result - Optimal solution found
Objective value: -0.00000000
Enumerated nodes: 0
Total iterations: 0
Time (CPU seconds): 0.21
Time (Wallclock seconds): 0.21
Option for printingOptions changed from normal to all
Total time (CPU seconds): 0.35 (Wallclock seconds): 0.35
- GUROBI
Using license file C:\Users\NAME\gurobi.lic
Set parameter LogFile to value gurobi.log
Gurobi Optimizer version 9.1.2 build v9.1.2rc0 (win64)
Copyright (c) 2021, Gurobi Optimization, LLC
Read LP format model from file C:\Users\Cian\AppData\Local\Temp\ce8521ad48894665b17cd0db5c63d23b-pulp.lp
Reading time = 0.11 seconds
OBJ: 2264 rows, 2021 columns, 209244 nonzeros
Thread count: 4 physical cores, 8 logical processors, using up to 8 threads
Optimize a model with 2264 rows, 2021 columns and 209244 nonzeros
Model fingerprint: 0xfc10ac4d
Variable types: 1032 continuous, 989 integer (989 binary)
Coefficient statistics:
Matrix range [1e-03, 3e+04]
Objective range [9e-03, 1e+01]
Bounds range [1e+00, 1e+00]
RHS range [2e+01, 2e+01]
Found heuristic solution: objective -0.0000000
Presolve removed 616 rows and 434 columns
Presolve time: 0.31s
Presolved: 1648 rows, 1587 columns, 49216 nonzeros
Variable types: 800 continuous, 787 integer (787 binary)
Root relaxation: cutoff, 42 iterations, 0.01 seconds
Nodes | Current Node | Objective Bounds | Work
Expl Unexpl | Obj Depth IntInf | Incumbent BestBd Gap | It/Node Time
0 0 cutoff 0 -0.00000 -0.00000 0.00% - 0s
Explored 0 nodes (42 simplex iterations) in 0.34 seconds
Thread count was 8 (of 8 available processors)
Solution count 1: -0
No other solutions better than -0
Optimal solution found (tolerance 1.00e-04)
Best objective -0.000000000000e+00, best bound -0.000000000000e+00, gap 0.0000%
Gurobi 在这个 运行
中比 CBC 差 ~0.5 秒
不要使用 GUROBI_CMD()，而是使用 GUROBI()，它使用 gurobi 的本机界面。
但老实说，在这种规模下，求解时间可能非常相似，以分钟为单位计算时，求解时间的巨大差异将体现出来。
我在 python 3.7 中使用 PuLP 设置了一个混合整数编程问题。 使用默认求解器 CBC，我的代码需要 3.9s。我想缩短时间以便加快速度，我去获得了 Gurobi 的学术许可证。 然而，当我使用它作为求解器时，它在 运行 时间上增加了将近一整秒：4.7s，与我希望的完全相反！
我通过 adding/updating 将这些行更新到设置中以使用 Gurobi 求解器（我认为这是正确的，因为它给出了相同的结果）：
solver = pl.GUROBI_CMD()
prob.solve(solver)
有谁知道速度慢的原因是什么？如果我想使用 gurobi，是否应该使用比 PuLP 更快的替代品来进行设置？
编辑：
这是日志文件：
- 加拿大广播公司
At line 2 NAME MODEL
At line 3 ROWS
At line 2301 COLUMNS
At line 219058 RHS
At line 221355 BOUNDS
At line 222359 ENDATA
Problem MODEL has 2296 rows, 2051 columns and 212512 elements
Coin0008I MODEL read with 0 errors
Continuous objective value is 0 - 0.03 seconds
Cgl0004I processed model has 1765 rows, 1704 columns (852 integer (852 of which binary)) and 54646 elements
Cbc0038I Initial state - 0 integers unsatisfied sum - 0
Cbc0038I Solution found of 0
Cbc0038I Relaxing continuous gives 0
Cbc0038I Before mini branch and bound, 852 integers at bound fixed and 852 continuous
Cbc0038I Mini branch and bound did not improve solution (0.14 seconds)
Cbc0038I After 0.14 seconds - Feasibility pump exiting with objective of 0 - took 0.01 seconds
Cbc0012I Integer solution of 0 found by feasibility pump after 0 iterations and 0 nodes (0.15 seconds)
Cbc0001I Search completed - best objective 0, took 0 iterations and 0 nodes (0.15 seconds)
Cbc0035I Maximum depth 0, 0 variables fixed on reduced cost
Cuts at root node changed objective from 0 to 0
Probing was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
Gomory was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
Knapsack was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
Clique was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
MixedIntegerRounding2 was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
FlowCover was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
TwoMirCuts was tried 0 times and created 0 cuts of which 0 were active after adding rounds of cuts (0.000 seconds)
Result - Optimal solution found
Objective value: -0.00000000
Enumerated nodes: 0
Total iterations: 0
Time (CPU seconds): 0.21
Time (Wallclock seconds): 0.21
Option for printingOptions changed from normal to all
Total time (CPU seconds): 0.35 (Wallclock seconds): 0.35
- GUROBI
Using license file C:\Users\NAME\gurobi.lic
Set parameter LogFile to value gurobi.log
Gurobi Optimizer version 9.1.2 build v9.1.2rc0 (win64)
Copyright (c) 2021, Gurobi Optimization, LLC
Read LP format model from file C:\Users\Cian\AppData\Local\Temp\ce8521ad48894665b17cd0db5c63d23b-pulp.lp
Reading time = 0.11 seconds
OBJ: 2264 rows, 2021 columns, 209244 nonzeros
Thread count: 4 physical cores, 8 logical processors, using up to 8 threads
Optimize a model with 2264 rows, 2021 columns and 209244 nonzeros
Model fingerprint: 0xfc10ac4d
Variable types: 1032 continuous, 989 integer (989 binary)
Coefficient statistics:
Matrix range [1e-03, 3e+04]
Objective range [9e-03, 1e+01]
Bounds range [1e+00, 1e+00]
RHS range [2e+01, 2e+01]
Found heuristic solution: objective -0.0000000
Presolve removed 616 rows and 434 columns
Presolve time: 0.31s
Presolved: 1648 rows, 1587 columns, 49216 nonzeros
Variable types: 800 continuous, 787 integer (787 binary)
Root relaxation: cutoff, 42 iterations, 0.01 seconds
Nodes | Current Node | Objective Bounds | Work
Expl Unexpl | Obj Depth IntInf | Incumbent BestBd Gap | It/Node Time
0 0 cutoff 0 -0.00000 -0.00000 0.00% - 0s
Explored 0 nodes (42 simplex iterations) in 0.34 seconds
Thread count was 8 (of 8 available processors)
Solution count 1: -0
No other solutions better than -0
Optimal solution found (tolerance 1.00e-04)
Best objective -0.000000000000e+00, best bound -0.000000000000e+00, gap 0.0000%
Gurobi 在这个 运行
中比 CBC 差 ~0.5 秒不要使用 GUROBI_CMD()，而是使用 GUROBI()，它使用 gurobi 的本机界面。
但老实说，在这种规模下，求解时间可能非常相似，以分钟为单位计算时，求解时间的巨大差异将体现出来。