CPLEX Python API performans ek yükü?

Question

Güncelleme

Bu soru iyice tartışılmış ve ben crossposted vardı OR exchange, üzerinde güncellendi.

Orijinal soru

komut satırından CPLEX 12.5.0.0 çalıştırdığınızda: optimal tamsayı çözümü 19.056,99 keneler bulunan

cplex -f my_instance.lp 

. Aynı örneğinde

Ama Python API üzerinden

:

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

gerekli zaman şimdi (en fazla 5 kat daha yavaş) 97.407,10 kene tutarındadır.

Her iki durumda da, mod paraleldir, determinist, en fazla 2 iş parçacığıdır. Bu kötü performans bazı Python iplik yükü yüzünden olsaydı merak denedim:

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

Gerekli 46.513,04 kene (yani tek bir çekirdek kullanarak iki kat daha hızlı ikisini kullanmaktan daha oldu!).

Genel olarak CPLEX ve LP için yeni olan bu sonuçları oldukça kafa karıştırıcı buluyorum. Python API performansını iyileştirmenin bir yolu var mı, yoksa daha olgun bir API'ye (yani Java veya C++) geçmeli miyim? Komut satırından

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) 

Sonuçlar::

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) 

Sonuçlar

Ek İşte

2-lifler kararlarının tam ayrıntıları, ilk (yaygın) önsöz vardır Python API'sinden:

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) 

Answer 1

Her iki durumda da önceliği devre dışı bırakmayı ve kesmeyi deneyebilirsiniz. Daha sonra, Python API'sinin kendisinin performansı düşürüp düşürmediğini test etmek için deneyi yeniden çalıştırın. Performans kesintileri devre dışı bırakıldıktan sonra eşleşirse, Python cut parametre ayarlaması & varsayılanlarına bakın.

Benim düşünceme göre performans için C++ tercih edilir, ancak geliştirme için ciddi zaman ekleyebilir. Sadece benim düşüncem olsa.

Answer 2

Bununla ilgili olarak, python API'sının, variable.add ve linear_constraints.add çağrılarından sonra bir sorun oluşturmak için oldukça uzun sürdüğünü fark ettim. CPXLgetcolindex den adlandırılan strcmp profilin çoğunu alıyor gibi görünüyor, belki de string ids bir dizi boyunca lineer aramalar kullanılarak ele alınır? C++ 'da problem yaratma anlıkdır.