5

更新

这个问题已经在我交叉发布的OR exchange上进行了彻底的讨论和更新。

原始问题

当我从命令行运行 CPLEX 12.5.0.0 时：

cplex -f my_instance.lp

在 19056.99 个刻度中找到了一个最优整数解。

但是通过 Python API，在同一个实例上：

import cplex
problem = cplex.Cplex("my_instance.lp")
problem.solve()

现在所需的时间为 97407.10 个滴答声（慢了 5 倍多）。

在这两种情况下，模式都是并行的、确定的、最多 2 个线程。想知道这种糟糕的性能是否是由于一些 Python 线程开销造成的，我尝试了：

problem = cplex.Cplex("my_instance.lp")
problem.parameters.threads.set(1)
problem.solve()

需要 46513.04 滴答（即，使用一个内核比使用两个内核快两倍！）。

作为 CPLEX 和 LP 的新手，我发现这些结果非常令人困惑。有没有办法提高 Python API 的性能，或者我应该切换到一些更成熟的 API（即 Java 或 C++）？

附件

以下是 2 线程解决方案的完整详细信息，首先是（通用）序言：

Tried aggregator 3 times.
MIP Presolve eliminated 2648 rows and 612 columns.
MIP Presolve modified 62 coefficients.
Aggregator did 13 substitutions.
Reduced MIP has 4229 rows, 1078 columns, and 13150 nonzeros.
Reduced MIP has 1071 binaries, 0 generals, 0 SOSs, and 0 indicators.
Presolve time = 0.06 sec. (18.79 ticks)
Probing fixed 24 vars, tightened 0 bounds.
Probing time = 0.08 sec. (18.12 ticks)
Tried aggregator 1 time.
MIP Presolve eliminated 87 rows and 26 columns.
MIP Presolve modified 153 coefficients.
Reduced MIP has 4142 rows, 1052 columns, and 12916 nonzeros.
Reduced MIP has 1045 binaries, 7 generals, 0 SOSs, and 0 indicators.
Presolve time = 0.05 sec. (11.67 ticks)
Probing time = 0.01 sec. (1.06 ticks)
Clique table members: 4199.
MIP emphasis: balance optimality and feasibility.
MIP search method: dynamic search.
Parallel mode: deterministic, using up to 2 threads.
Root relaxation solution time = 0.20 sec. (91.45 ticks)

命令行的结果：

GUB cover cuts applied:  1
Clique cuts applied:  3
Cover cuts applied:  2
Implied bound cuts applied:  38
Zero-half cuts applied:  7
Gomory fractional cuts applied:  2

Root node processing (before b&c):
  Real time             =    5.27 sec. (2345.14 ticks)
Parallel b&c, 2 threads:
  Real time             =   35.15 sec. (16626.69 ticks)
  Sync time (average)   =    0.00 sec.
  Wait time (average)   =    0.00 sec.
                          ------------
Total (root+branch&cut) =   40.41 sec. (18971.82 ticks)

Python API 的结果：

Clique cuts applied:  33
Cover cuts applied:  1
Implied bound cuts applied:  4
Zero-half cuts applied:  10
Gomory fractional cuts applied:  4

Root node processing (before b&c):
  Real time             =    6.42 sec. (2345.36 ticks)
Parallel b&c, 2 threads:
  Real time             =  222.28 sec. (95061.73 ticks)
  Sync time (average)   =    0.01 sec.
  Wait time (average)   =    0.00 sec.
                          ------------
Total (root+branch&cut) =  228.70 sec. (97407.10 ticks)
4

2 回答 2

1

您可以尝试在这两种情况下禁用预求解器和切割。然后重新运行实验以测试 Python API 本身是否会限制性能。如果禁用剪切后性能匹配，则查看 Python 剪切参数调整和默认值。

在我看来，C++ 在性能方面是首选，但它会增加开发时间。不过只是我的看法。

于 2013-09-12T19:40:24.637 回答
0

与此相关，我注意到在调用 variables.add 和 linear_constraints.add 之后，python API 需要更长的时间来构建问题。似乎从 CPXLgetcolindex 调用的 strcmp 占用了大部分配置文件，也许字符串 id 正在使用通过数组的线性搜索来处理？在 C++ 中，问题的产生是瞬时的。

于 2013-10-02T23:42:29.943 回答