An Interface Design for General Parallel Branch-and-Bound Algorithms
Yuji Shinano?, Masahiro Higaki and Ryuichi Hirabayashi Science University of Tokyo 1-3, Kagurazaka, Shinjuku-ku, Tokyo 162, Japan E-mail:
[email protected] Branch-and-Bound algorithms are general methods applicable to various combinatorial optimization problems. There are two hopeful methods to improve the algorithms. One is development of the algorithms which exploit the structure of each problem. The other is parallelization of the algorithms. These two methods have been studied by di erent research communities independently. If a well-designed interface separating the two kinds of implementation of the methods clearly could be constructed, it would enable us to adapt latest algorithms or technology easily. In this paper, we propose a small and simple interface design of a generalized system for parallel branch-and-bound algorithms. Key words: parallel processing, combinatorial optimization problem, branchand-bound algorithms. Abstract.
1 Introduction
Branch-and-bound algorithms are general methods applicable to various combinatorial optimization problems. These algorithms are search-based techniques that enumerate the entire solution space implicitly. In order to perform this enumeration eciently, it is necessary to limit the number of feasible solutions that need to be explicitly produced. This process can be accomplished by clever algorithms, which exploit the structure of each problem, and many complicated algorithms have been proposed for each problem. We call implementations of such algorithms problem depending implementation. Unfortunately, even if such procedures are applied, some instances of the problems cannot be solved in a reasonable amount of time. Parallelization is one of the most hopeful methods to accelerate the enumeration speed. We consider high-level parallelism of such algorithms. In such kinds of applications of parallelism, generality of the branch-and-bound algorithm framework should be maintained. Therefore, it is reasonable to develop a generalized system that provides the general framework of the parallel branch-and-bound algorithms and some facilities to make use of it. There are several architectures of parallel computers and several ways to map the framework on a architecture of them. Therefore, many implementations of high-level parallelism should be considered. We call an implementation of the parallelism parallelization architecture depending implementation . ?
Supported by JSPS Research Fellowships for Young Scientists.
We consider all parallelization architecture depending implementations to be embedded into the generalized system. Then an interface of the generalized system is not only a boundary of the general framework of the parallel branch-and-bound algorithms and their applications, but also a boundary of the two kinds of implementations. These two kinds have been studied by di erent research communities. Therefore, if the two kinds of implementations are separated completely in the generalized system, it would enable latest algorithms or technology to be applied easily. Hence, the interface design is very important. There are two approaches to make such a generalized system. One is to develop a generalized system from general formulations [1, 6]. The other is to generalize techniques derived from speci c problem implementations [10]. The rst approach usually provides a good sophisticated interface design but has problems in implementation. That is, the implementation does not always achieve sucient eciency. The second approach is quite successful (in terms of eciency) for some problems but it is usually not so sophisticated as the rst. On the development of the generalized system, data types used in the problem depending implementation are unspeci ed. In order to maintain the generality of the system and to provide an interface that separates the two kinds completely, abstract data type is necessary. In this paper, we provide a model of a generalized system based on an object-oriented paradigm and an interface design using the object-oriented programming language C++ which is widespread and accessible to many researchers. 2
General branch-and-bound algorithms
We assume, without loss of generality, that the combinatorial optimization problem we wish to solve is posed as the minimization problem: P0 : minimize f (x) subject to x X0 where X0 is a discrete set. A general branch and bound algorithm for solving P0 is presented as follows. In the algorithm, z~ maintains the latest found upper bound of z0 and is called an incumbent value of P0 , while x~ (a solution corresponding to z~) is an incumbent solution of P0 . 1 procedure General branch and bound algorithm(GBBA) ; 2 begin 3 z~ := + ; L := P0 ; initialization 4 while L = do 5 begin 6 Select a subproblem P from L; i 7 L := L Pi ; 8 Solve P 's relaxation problem RP i i 9 if an optimal solution of RP exists then i R 10 Let zi be the optimal value of RP i R and xi be an optimal solution of RP i R 11 if zi getInitialSolution(); pRootProblem = pInitData->getRootProblem(); } }; int main( int argc, char* argv ){ TspProblemManager* pPm = new TspProblemManager( ... ); TspSolver* pSolver = new TspSolver(); pSolver->solve( pPm ); pPm->printSolution(); delete pSolver; delete pPm; return 0; }
The main function and the de nition of TspProblemManager
The initialization procedure in GBBA(line 3) corresponds to the construction of the Problem Manager(line 11 and line 3-6) and the result output procedure in GBBA(line 23-26) corresponds to the printSolution call of the Problem Manager(line 14). Other parts of GBBA correspond to the codes of the solve function of the Solver. The skeleton in the solve member function has much
exibility, because it has small interfaces and less restriction on the usage of
the member functions of the Problem Manager. The only restrictions are that getSubproblem needs to be called at the beginning of an evaluation (line 13) and removeSubproblemBySolved (line 21) to be called at the end of an evaluation. The number of calls of putSubproblem is the number of branches from the Subproblem obtained from the Problem Manager at the beginning of an evaluation. Some low-level parallelism can be implemented here (line 20). 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
class TspSolver : public SolverBase { public: void solve(ProblemManagerBase*); private: }; void TspSolver::solve( ProblemManagerBase* pPmBase ){ TspProblemManager* pPm = (TspProblemManager*)pPmBase; TspInitData* pIDat = (TspInitData*)pPm->getInitData(); while( TspSubproblem* pSpb = (TspSubproblem*)pPm->getSubproblem() ){ if ( pSpb->shallIUseInternalVariables() == SubproblemBase::YOU_SHOULD_NOT_USE_IT ){ // Initialize internal variables } else { // Use internal variables of the previous calculation } // Routines for an evaluation : pPm->removeSubproblemBySolved( pSpb ); } } Fig. 4.
5
The de nition of TspSolver
On the development of a generalized system
Implementations of the Problem Manager are the greater part of a generalized system development. The Problem Manager can handle transported objects as abstract data types and also its internal architecture (single-pool or multiple-pools, synchronous or asynchronous) is hidden from the Solver. Hence program codes for problem depending implementations can exchange from one parallelization architecture depending implementation to another without any modi cation. In this context, a sequential architecture is considered as a special case of parallelization architecture. Therefore, program codes for the problem depending implementation presented in the skeleton of the previous section can translate to parallel platforms without being changed them. In some parallelization architecture, it may be necessary that Problem Manager maps on several processors and all of its functions are realized by several modules. In such a case, the designer of a generalized system needs to make a kind of other classes which are derived from the base class of the Problem Manager with respect to the mapping. Even if such a mapping changes internal architecture of the Problem Manager, all services provided in the base class can be inherited. The main functions should be provided by the generalized
systems, because the number of main functions and the codes written in it need to be changed depending on the architecture. For example, when the is composed of several modules, the module on which procedures of data input and results output are performed depends on the architecture. The derived class of the is closely related to the parallelization architecture used and it should be written mechanically. Therefore, the main functions and the derived class of the should be generated by the system. A synchronization paradigm is realized as an implementation of the member function getSubproblem in the . In a synchronized implementation, the function waits to return a until an evaluation calculated in all s has nished. In a asynchronous implementation, the function returns a immediately as long as the subproblem pools are not empty.
Problem
Manager
Problem Manager Problem Manager
Solver Subproblem
Problem Manager Subproblem
6 Discussion We checked if our proposed interface did not lose generality of branch-and-bound algorithms by comparing with several general formulations [1, 4, 5, 8]. As a result, we found out that our implementation does not support pruning by dominance test[3]. However, it can be supported only by adding a declaration of the public member function dominated(IntDataBase*, SubproblemBase*) on the base class of the and realized in the derived class. This member function returns true when the is dominated by the that is given by the argument. If this member function is implemented in the base class, it would be possible for the to perform the dominance test. In our model, the representations of a subproblem (and solution) force the programmer to divide the and the (the and the ) explicitly. The should have all xed parts of transported objects, because it is usually transmitted only once throughout the calculation. While the (and the ) has variable parts, it may be transmitted many times. In order to reduce the amount of transmission data, the size of the data members in the (and the ) should be as small as possible. The transmission costs heavily depend on the data structure to represent them. It is good for the programmer to be conscious of this division without being concerned about the way of parallelization, because the method of making the (and the ) small is the parts problem depending implementation.
Subproblem Subproblem Subproblem Problem Manager Subproblem InitData Solution InitData InitData Subproblem Solution Subproblem Solution Subproblem
Solution
7 Concluding remarks In this paper, we proposed an interface design of a generalized system based on an object-oriented paradigm for parallel branch-and-bound algorithms. It separates the problem depending implementation and parallelization architecture
depending implementation clearly with small interfaces, so that it is exible on both sides. We provided a skeleton in problem depending implementation and showed a guideline of how to make a generalized system using our model. Furthermore, a generalized system using our model has been already realized on renewed PUBB(Parallelization Utility for Branch-and-Bound algorithms)[9], though the precise speci cation of member functions were not presented in this paper, due to space restrictions. Many implementations for parallel branch-and-bound algorithms have appeared [2]. However, the situation is confused when we try to compare them with each other, because the two kinds of implementations are usually mixed. Therefore, we need a standard interface. If a standard interface could be provided, it would enable us not only to use the latest algorithms and technology easily but also to compare the implementations accurately. It would give more clear insight into the e ectiveness of parallelization of the algorithms.
Acknowledgments
We would like to thank Yoshiko Ikebe for reading the draft so many times and the anonymous referees for the helpful suggestions.
References Parallel Algorithms for Irregularly Structured Problems, A.Ferreira and J.Rolim(eds.), LNCS 980, 395-409, Springer, 1995.
1. R.Corr^ ea. A Parallel Formulation for General Branch-and-Bound Algorithms.
2. B.Gendron and T.G.Crainic. Parallel Branch-and-Bound Algorithms: Survey and
Synthesis. Operations Research, 42(6):1042-1066, 1994. 3. T.Ibaraki. The Power of Dominance Relations in Branch-and-Bound Algorithms.
Journal of the ACM, 24(2):264-279,
1977.
4. T.Ibaraki. Branch-and-Bound Procedure and State-Space Representation of Combinatorial Optimization Problems. Information and Control, 36:1-27, 1978. 5. V.Kumar and L.N.Kanal. A General Branch and Bound Formulation for Understanding and Synthesizing And/Or Tree Search Procedures. Arti cial Intelligence, 21:179-198, 1983. 6. G.P.McKeown, V.J.Rayward-Smith and H.J.Turpin. Branch-and-Bound as a Higher-Order Function.
Annals of Operations Research, 33:379-402,
1991.
7. G.P.McKeown, V.J.Rayward-Smith and S.A.Rush. Parallel Branch-and-Bound.
Advances in Parallel Algorithms, L.Kronsjo and D.Shumsheruddin(eds.), Advanced topics in computer science, 111-150, Blackwell, 1992.
8. D.S.Nau, V.Kumar and L.Kanal. General Branch and Bound, and Its Relation to A
3
and A
O 3 . Arti cial Intelligence, 23:29-58, 1984.
9. Y.Shinano, M.Higaki and R.Hirabayashi. A Genearlized Utility for Parallel Branch
Proc. of the 7th IEEE Symposium on Parallel and Distributed Processing, 392-401, IEEE Computer Society Press, 1995.
and Bound Algorithms.
10. S.Tch oke, R.L uling and B.Monien. Solving the Traveling Salesman Problem with
Proc. of the 9th International Parallel Processing Symposium, Santa Barbara, CA , April a Distributed Branch-and-Bound Algorithm on a 1024 Processor Network.
1995. To appear.
