Concurrent optimizer in parallel

Describes the concurrent optimizer.

On a multiprocessor computer, the concurrent optimizer launches distinct LP and QP optimizers on multiple threads, terminating as soon as the first optimizer finishes. The first thread uses the same strategy as the single-processor automatic setting (0 zero) of the algorithm for continuous linear problems (CPX_PARAM_LPMETHOD, RootAlg) or algorithm for continuous quadratic optimization (CPX_PARAM_QPMETHOD, RootAlg) depending on the problem type. If a second thread is available, the concurrent optimizer runs the barrier optimizer on it.

The behavior of the concurrent optimizer depends on the number of threads. The more threads that are available, CPLEX will then concurrently run more algorithms. If only a single thread is available, Dual Simplex will be used. As more threads become available, CPLEX will consider also trying Barrier, Primal Simplex, or Sifting. See the log for what algorithms are executed concurrently on how many threads each.

LP with large aspect ratio

When the concurrent optimizer is invoked on a linear program (LP), it checks the aspect ratio of the model. If the aspect ratio is large, and if more than 10 (ten) threads are available to CPLEX, then concurrent optimization also invokes sifting on the LP. For more information about sifting, see the topic Sifting optimizer.

Finishing first: basis solution in concurrent optimization

Barrier optimization is not considered complete until the crossover step has been performed and simplex re-optimization has converged; in other words, regardless of which optimizer turns out to be the fastest, the concurrent optimizer always returns a basis solution at optimality.

Performance trade-offs in concurrent optimization

The concurrent optimizer requires more memory than any individual optimizer, and of course it adds system load by consuming more aggregate CPU time than the fastest individual optimizer would alone. However, the advantages offered in terms of robust solution of models, and assurance in most cases of the minimum solution time, will make it attractive in many situations.

Interpreting the log in concurrent optimization

When you invoke concurrent optimization in your application, you may observe a point in the log when CPLEX® reports a solution of the model by an optimizer, but no other report of activity appears in the log for a considerable time afterward. During this apparently inactive period, concurrent optimization deterministically manages potential race conditions among competing optimizers. Among other decisions during this period, the concurrent optimizer decides deterministically from which of those competing optimizers to accept the final solution.

If this apparent wait during the race between concurrent optimizers poses a problem for your application, there are two alternative remedies available to you:

  • Use opportunistic mode, rather than the default deterministic mode. To do so, change the setting of the parallel mode switch (CPX_PARAM_PARALLELMODE, ParallelMode) documented in the CPLEX Parameters Reference Manual.

  • Set the optimizer that consistently solves your model first as the starting algorithm in your application.

    To do so, set the parameter appropriate for your type of model:

Callbacks and concurrent optimization

Because of considerations about thread safety and predictable behavior, concurrent optimization should not invoke any callbacks except in the first, main thread.