Originally posted by: SystemAdmin

[reichel said:]

Hi,

in my experiments I have observed that CPLEX 11 is much slower that CPLEX 10.1. For example, for a particular instance size I get

CPLEX 10.1: 938s (user) / 45s (sys)
CPLEX 11.0: 1229s (user) / 1676s (sys)

I should mention that in my benchmark I solve millions of very small IPs (around 10 variables, 15-20 constraints). I'm not happy about the increased user time which probably can be explained by increased overhead necessary for new features etc. But the bigger problem is the time spent in syscalls which is about 30x larger than before. This has been observed on several i386 and amd64 CPUs, with 32bit/64bit and in release/debug mode.

Using strace I get the following data:

CPLEX 10.1:
139548 times
3431 brk
(other syscalls with very low numbers, independent of problem size omitted)

The times() calls seem to be necessary to obey time limits.

CPLEX 11.0:
147217          times
67379          read
33708          mmap
33696          close
33695          fstat
33687          munmap
8659          brk
(other syscalls with very low numbers, independent of problem size omitted)

About 81% of the time spent in syscalls is spent in read().

Is there a way to disable the new behaviour in CPLEX 11?

Regards,
  Joachim
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

[pgerard said:]

Maybe the slowdown you witnessed is due to the new "dynamic search" algorithm implemented by default in CPLEX 11 when solving MIPs.

You can change back to good old Branch&Cut strategy by setting the parameter MIPSearch to the CPX_MIPSEARCH_TRADITIONAL value.

I also experience performance problems with CPLEX 11, but rather when solving large MIP models (say several 1000 integer variables). The "old" search strategy performs slightly better, but still not as well as CPLEX 10.1 ???

#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

[reichel said:]

Hi,

thanks for the hint, I wasn't aware of this parameter. But It doesn't help in my case. My problems are so small that there is not much branching. The high number of sycalls rather indicates that this is some problem below the algorithmic level (memory management, timing, etc.) In fact, it turned out that CPLEX reads /proc/stat 6-7 times per IP (which is a lot if you solve ~1000 IPs per second).

I'm in contact with ILOG support to get this fixed. But the exact cause for this problem is not yet clear (at last they did not tell me yet).

Joachim

#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

[reichel said:]

The bug has been identified and will be fixed in 11.0.1.

#CPLEXOptimizers
#DecisionOptimization