CPLEX、Gurobi 和 FICO Xpress 之间的性能差异的解释使用内点法（障碍）没有交叉？

Posted 2023-03-17

【中文标题】CPLEX、Gurobi 和 FICO Xpress 之间的性能差异的解释使用内点法（障碍）没有交叉？

【英文标题】：Explanation of difference in performance between CPLEX, Gurobi and FICO Xpress using interior point method (barrier) without crossover?

【发布时间】：2019-03-21 19:38:02

【问题描述】：

我正在使用一个非常大的（随机）LP 使用没有交叉的障碍算法。我的模型是在 Pyomo 中实现的，我尝试使用 CPLEX、Gurobi 和 FICO Xpress 来解决它。 Pyomo 中的求解器设置如下：

对于 CPLEX：

opt = SolverFactory("cplex")
opt.options["lpmethod"] = 4
opt.options["barrier crossover"] = -1
results = opt.solve(instance)

对于古罗比：

opt = SolverFactory('gurobi_persistent')
opt.set_instance(instance)
opt.options["Crossover"]=0
opt.options["Method"]=2
results = opt.solve(instance, load_solutions=True)
results = opt.load_vars()
results = opt.load_duals()

对于 FICO Xpress：

opt = SolverFactory("xpress")
opt.options["defaultAlg"] = 4
opt.options["crossover"] = 0
results = opt.solve(instance)

所有求解器都能找到解决方案，但速度（非常）不同：

Gurobi 使用 337 次迭代在 4593 秒 (9.98262837e+11) 内找到次优解 FICO Xpress 使用 169 次迭代在 7981 秒 (9.98246410e+11) 内找到最优解 CPLEX 使用 258 次迭代在 40,178 秒 (9.98250954e+11) 内找到次优解

我的问题是：为什么求解器之间存在如此巨大的差异（尤其是比较 CPLEX 和 Gurobi）？不同的障碍算法发生了什么？

CPLEX 的日志摘要：

IBM(R) ILOG(R) CPLEX(R) Interactive Optimizer 12.8.0.0
Read time = 52.61 sec. (3283.43 ticks)
Objective sense      : Minimize
Variables            : 17684371
Objective nonzeros   : 7976817
Linear constraints   : 26929486  [Less: 25202826,  Equal: 1726660]
  Nonzeros           : 83463204
  RHS nonzeros       :  621453
Tried aggregator 1 time.
DUAL formed by presolve
Aggregator has done 14545 substitutions...
LP Presolve eliminated 8512063 rows and 3459945 columns.
Reduced LP has 14209881 rows, 21009396 columns, and 61814653 nonzeros.
Presolve time = 148.20 sec. (209740.04 ticks)
Parallel mode: using up to 24 threads for barrier.
***NOTE: Found 243 dense columns.
Number of nonzeros in lower triangle of A*A' = 268787475
Elapsed ordering time = 17.45 sec. (10000.00 ticks)
Using Nested Dissection ordering
Total time for automatic ordering = 376.13 sec. (209058.23 ticks)
Summary statistics for Cholesky factor:
  Threads                   = 24
  Rows in Factor            = 14210124
  Integer space required    = 145889976
  Total non-zeros in factor = 12261481354
  Total FP ops to factor    = 39156639536792
Total time on 24 threads = 40177.89 sec. (62234738.71 ticks)
Barrier - Non-optimal:  Objective =  9.9825095360e+11
Solution time = 40177.90 sec.  Iterations = 258

Xpress 的日志摘要：

FICO Xpress Solver 64bit v8.5.0:
Problem Statistics
    26929486 (      0 spare) rows
    17684371 (      0 spare) structural columns
    83463204 (      0 spare) non-zero elements
Presolved problem has:
  18426768 rows     14805105 cols     59881674 elements
Barrier cache sizes : L1=32K L2=20480K
Using AVX support
Cores per CPU (CORESPERCPU): 12
Barrier starts, using up to 24 threads, 12 cores
Matrix ordering - Dense cols.:   6776   NZ(L): 485925484   Flops: 273369311062
Barrier method finished in 7874 seconds
Optimal solution found
Barrier solved problem
  169 barrier iterations in 7981s
Final objective                         : 9.982464100682021e+11
Max primal violation      (abs / rel) : 1.612e-03 / 1.612e-03
Max dual violation        (abs / rel) : 1.837e+02 / 7.381e+01
Max complementarity viol. (abs / rel) : 1.837e+02 / 1.675e-07

Gurobi 的日志摘要：

Gurobi 8.0.0: 
Optimize a model with 26929485 rows, 17684370 columns and 83463203 nonzeros
Coefficient statistics:
  Matrix range     [1e-05, 4e+00]
  Objective range  [2e+00, 8e+06]
  Bounds range     [0e+00, 0e+00]
  RHS range        [1e-01, 2e+08]
Presolve removed 8527789 rows and 2871939 columns
Presolve time: 53.79s
Presolved: 18401696 rows, 14812431 columns, 59808411 nonzeros
Ordering time: 29.38s
Barrier statistics:
 Dense cols : 4607
 AA' NZ     : 6.262e+07
 Factor NZ  : 5.722e+08 (roughly 18.0 GBytes of memory)
 Factor Ops : 3.292e+11 (roughly 4 seconds per iteration)
 Threads    : 12
Barrier performed 337 iterations in 4592.92 seconds
Sub-optimal termination - objective 9.98262837e+11

【问题讨论】：

解决方案时间取决于实现。不确定是否可以获得比这更详细的答案，因为它需要了解底层的实现细节。请注意，逐个实例也存在很大差异（例如，请参阅here）

你写“实现”依赖是什么意思？你的意思是障碍算法是如何在三个不同的求解器中实现的？这三个实例的底层 lp 文件完全相同。

是的，确切地说：有几种设计选择并不明确，在某些条件下效果很好，而在其他条件下效果不佳。也可能存在其他差异，例如使用的数据结构、基本算法（例如使用哪种排序）、数字、预处理强度等。Here 是 Clp 的源代码，CPLEX 的前身，这说明了开发商业求解器所涉及的复杂性。

可以尝试减少 Cplex 的线程数吗？ （检查您的内存使用情况）。您可能还需要考虑稍微扩展您的模型。

是的，我会试试的。注意到与 Gurobi 相比，CPLEX 使用了大约两倍的处理能力和内存。你是什​​么意思缩放？比如，将整个目标函数除以 1 000 000？

【参考方案1】：

使用 CPLEX，因式分解的成本要高得多。

#FLOPS CPLEX  ~3.92e+13
#FLOPS Xpress ~2.73e+11
#FLOPS Gurobi ~3.29e+11

我已经多次看到大型 LP 出现这种差异。在大多数情况下，CPLEX 做出了错误的决定，将对偶传递给优化器

DUAL formed by presolve

将 PreDual 参数设置为 -1 可以防止这种情况发生。