This section describes theMulti-Path Simplex Algorithm, an externally parallel algorithm that uses parallel threads to solve a linear programming problem with different configurations to solve a linear programming problem. The parallel algorithm runs several instances of the algorithm in individual threads with different pricing algorithms. The configuration parameters could also include some combination of different ratio test algorithms or others. When a user considers the number of threads that are available to the solver as well as the available memory, the number of parallel combinations can be tailored to a specific machine.
Algorithm 6 presents theMulti-Path Simplex Algorithm. This shows the details for parallel execution including the usage of a mutex and atomic variables. The mutex in this algorithm ensures there are no race conditions and the atomic booleans allow cancellation of a solver from multiple threads. The inputs to the algorithm are a list of configured solver instances that are parametrized based on command line options for the executable.
The first portion of the algorithm allocates resources by instantiating a mutex and forming a dictionary that links each of the solvers to an atomic boolean variable. This variable is initially set to false to indicate that a solution has yet to be found. The solver checks whether or not it has been set to true at each iteration of the algorithm. When the cancel switch is set to true, the solver is terminated. The atomics do not cause delays as there is little competition for access between threads.
Next, the solve method is called for each solver within individual threads and the first to find a solution obtains the mutex. The solution from this solver is stored, the solved flag is set to true, and the other solvers are canceled. As each solver exits the main loop with a partial solution to the problem, it obtains the mutex, but infers that a solution has already been obtained. They release the mutex and the parent thread returns the winning solution.
Algorithm 6Multi-Path Simplex Algorithm
1: procedureSimplex(solvers,problem)
2: solved ← f alse
3: mtx ← Mutex()
4: cancel← Dictionary()
5: for each solver∈solversdo
6: cancel[solver]= solver.getAtomicCancelBoolean()
7: end for
8: parallel forsolver ∈solversdo
9: solver.solve(problem)
10: mtx.lock()
11: if notsolvedthen
12: solution← solver.solution()
13: solved← true
14: for eachother ∈ solversdo
15: if other, solverthen
16: cancel[other].store(true)
17: end if 18: end for 19: end if 20: mtx.unlock() 21: end parfor 22: 23: return solution 24: end procedure
4.4. TheMulti-PathSimplexAlgorithm 73
4.4.1
Algorithm Configurations
The performance of theSimplex Algorithmdepends on the input configuration parameters. The option to run multiple pricing algorithms in parallel creates a software with a greater number of configuration options than the sequential software. This section presents an analysis of the maximum possible benefits that can be achieved with multi-path parallelism based on the configuration parameters that are chosen and presents rationale for selecting a parallel solver over a traditional solver.
In the ideal scenario, each parallel configuration would show performance that surpasses any of the possible sequential configurations. This ideal performance is not achievable due to the nature of theSimplex Algorithmas shown by Lemma 4.4.1.
Lemma 4.4.1. Any implementation of the Simplex Algorithm has at least one pricing algorithm that will result in the global minimum runtime to solve a specific linear programming problem. This minimum runtime can only be found if the problem is solved with every available pricing algorithm.
Proof. Assume a solver has a set ofPunique pricing algorithms available for solving a linear programming problem. Each p ∈ P corresponds to a specific path that is followed along the edges of the constraint polyhedron from the initial basis to the final basis. Each path is likely to have a different length,Np, and visit a different set of variables. The total time required to solve
the linear programming problem for a pricer pis given by (4.1) wheretpi is the time taken for
iteration,i, andtpis the total time.
tp = Np
X
i=1
tpi (4.1)
For any pricer, each tpi is likely to vary as the sparsity of the data structures changes
throughout iterations. However, the overall behavior can be predicted with complexity analy- sis. The total number of stepsNp, however, cannot be predicted and is an open problem [12].
The set of run times for each pricer is thus unknown prior to actually solving the problem. Within this set there will be one minimum, which could be repeated in the event of a tie be- tween two of the algorithms. Therefore there is one global minimum runtime for a given linear
programming problem and this value can only be quantified by solving the problem with each
pricer.
Given that user is likely to solve their model once, and that the optimal pricing algorithm is impossible to predict, the parallel algorithm increases the probability that a solution is found. For example, SoPlex contains five pricing algorithms. If multiple of these are run simultane- ously, the probability that the optimum algorithm is chosen scales linearly with the number of threads. Each additional thread adds twenty percent to the probability that the optimum configuration is chosen in the first attempt to solve the problem. The algorithm reduces the probability that a solution is never found due to a high level of degeneracy, where the algo- rithm cycles between two variables for an indeterminate amount of time.