Paradiseo: From a Modular Framework for Evolutionary Computation to the Automated Design of Metaheuristics —22 Years of Paradiseo—
Johann Dreo1, Arnaud Liefooghe2, S´ebastienVerel3, Marc Schoenauer4, Juan J. Merelo5, Alexandre Quemy6, Benjamin Bouvier7, and Jan Gmys8
1Systems Biology Group, Depepartment of Computational Biology, USR 3756, Institut Pasteur and CNRS, Paris, France. [email protected] —Corresponding author. 2Univ. Lille, CNRS, Inria, Centrale Lille, UMR 9189 CRIStAL, F-59000 Lille. [email protected] 3 Univ. Littoral Cˆoted’Opale, Calais, France. [email protected] 4TAU, Inria, CNRS & UPSaclay, LISN, Saclay, France. [email protected] 5University of Granada, Granada, Spain. [email protected] 6Poznan University of Technology, Poznan, Poland. [email protected] [email protected] 8Inria, Lille, France. [email protected]
Abstract ical approaches, numerous applications have shown the efficiency of those randomized search heuristics. The success of metaheuristic optimization methods However, following Wagner et al. [33], we observe that has led to the development of a large variety of al- the metaheuristic research domain lacks mature soft- gorithm paradigms. However, no algorithm clearly ware, while it is crippled with short-lived research dominates all its competitors on all problems. In- prototypes on over-specific features sets. We believe stead, the underlying variety of landscapes of opti- this state hinders the adoption of those technologies mization problems calls for a variety of algorithms to in the industrial world and is an obstacle to break- solve them efficiently. It is thus of prior importance through innovations. Therefore, the development of a to have access to mature and flexible software frame- full-featured and mature metaheuristic optimization works which allow for an efficient exploration of the framework is of prior importance, for both the scien- algorithm design space. Such frameworks should be tific and the applied communities. In this article, we flexible enough to accommodate any kind of meta- summarize our efforts towards this goal, in the guise heuristics, and open enough to connect with higher- of the Paradiseo project. level optimization, monitoring and evaluation soft- The Paradiseo framework is a 22 years old effort wares. This article summarizes the features of the which aims at developing a flexible architecture for Paradiseo framework, a comprehensive C++ free soft- the generic design of metaheuristics for hard opti- arXiv:2105.00420v1 [cs.NE] 2 May 2021 ware which targets the development of modular meta- mization problems. It is implemented in C++, a very heuristics. Paradiseo provides a highly modular archi- mature object-oriented programming language,which tecture, a large set of components, speed of execution is probably one of the fastest, if not the fastest, and automated algorithm design features, which are object-oriented programming platforms on the mar- key to modern approaches to metaheuristics develop- ket [19, 30, 28]. It is also highly portable and ben- ment. efits from very extensive tooling as well as an active community. Paradiseo is released as a free and open- 1 Introduction source software, under the LGPL-v2 and CeCILL li- censes (depending on the module). Its development In the research domain of metaheuristics for black- is open and the source code is freely available on the 1 2 box optimization, a very large variety of algorithms Inria and Github code repositories. has been developed since the first Evolution Strategies appeared in 1965 [31]. Starting from nature-inspired 1https://gitlab.inria.fr/paradiseo/paradiseo computing methods and following recent mathemat- 2https://github.com/jdreo/paradiseo
1 1.1 History Table 1: Main software frameworks for evolutionary The “Evolving Objects” (EOlib, then simply EO) computation and metaheuristics. Fastest languages framework was started in 1999 by the Geneura team are figured in green and slowest in red, copyleft li- at the University of Granada, headed by Juan Juli´an censes are in red. “kloc” stands for “thousands of Merelo. The development team was then reinforced lines of code”. e h v n s i s r c t g r i e o by Maarten Keijzer, who designed the current mod- c t e a s p e e j u e e g r a e r a b b c o S U D e i s
e t s u s c o l r . P e t . s i i n a t e l
ular architecture, and Marc Schoenauer [21]. Later g a d t t o s t e c l G l A d n O t m o c n n u a c o u u P a p o l u v D S t a i o a l came Jeroen Eggermont, who, among other things, N L U L C k E E P L C M G M L S A ParadisEO C++ 2021 LGPLv2 33 82 Y Y Y Y Y Y ~ Y Y Y Y did a lot of work on genetic programming, Olivier jMetal Java 2021 MIT 29 60 Y N Y N Y N N Y N ? N ECF C++ 2017 MIT 19 15 Y N Y N Y N N N N Y N K¨onig,who did a lot of useful additions and cleaning ECJ Java 2021 AFLv3 33 54 Y Y Y N Y Y Y Y N Y N DEAP Python 2020 LGPLv3 45 9 Y N N N Y Y N Y N Y N of the code, and Jochen K¨upper. CIlib Scala 2021 Apachev2 17 4 Y N N N N N N N N ? N HeuristicLab C# 2021 GPLv3 20 150 Y N Y Y Y Y N Y ~ Y N The Inria Dolphin team, headed by El-Ghazali Clojush Clojure 2020 EPLv1 17 19 Y N N N N N N N N N N Talbi, did a lot of contributions starting from around 2003, on their own module collection called Paradiseo. Thomas Legrand worked on particle swarm optimiza- lists 57 software packages related to the implementa- tion, the regretted S´ebastienCahon and Nouredine tion of evolutionary algorithms (among which EOlib, Melab worked on parallelization modules [7,6,4,5]. the ancestor of Paradiseo). Arnaud Liefooghe and J´er´emieHumeau worked a lot Most of those software are now unmaintained or on the multi-objective module [24] and on the local impossible to find. There has been, however, a con- search one along with S´ebastienVerel [18]. In the stant flow of new frameworks, library or solvers every same team, C. FC.3 and Jean-Charles Boisson made year, for decades. We were able to find at least 47 7 significant contributions. of them readily available on the web . Among those The (then) EO project was taken over by Johann projects, only 8 met all the following criteria: Dreo, who worked with the help of Caner Candan on 1. open-source framework aiming at designing algo- adding the EDO module. Johann and Benjamin Bou- rithms8, vier have also designed a MPI parallelization module, while Alexandre Quemy also worked on paralleliza- 2. being active since 2015, tion code. In 2012, the two projects (EO and Paradiseo) were 3. having more than 15 contributors. merged into a single one by Johann Dreo, S´ebastien The features of those main frameworks are compared Verel and Arnaud Liefooghe, who have been acting in Table1, where the number of lines of code was com- as maintainers ever since. puted with the cloc tool9. Note that for HeuristicLab, In 2020, automated algorithm selection design and the code for the GUI modules was excluded from the binding toward the IOHprofiler validation tool were count. The GPGPU module of Paradiseo [27] is not added by Johann Dreo. counted either, as it is not maintained anymore. The Along the life of the project, several spin-off soft- number of contributors has been retrieved from the ware have been developed, among which a port of code repository’s commit histories, which underes- the EO module in Java [1], another one in ActiveX4; timates the number of people involved in the case GUIDE, a graphical user interface for assembling al- of Paradiseo; the extracted number is however kept, gorithms [10]5, and EASEA, a high-level declarative for fairness in comparison with the other frameworks, language for evolutionary algorithm specification [9], that might face a similar bias. which later became independent [26] of the specific Among the software close in features to Paradiseo, library. ECF has not been updated in 4 years. ECJ, jMetal
edu/pub/doc/EC/FAQ/www/Q20.htm 1.2 Related Frameworks 7Paradiseo, jMetal, ECF, OpenBeagle, Jenetics, ECJ, The 1998’s version of the hitch-hiker’s guide to evo- DEAP, CIlib, GP.NET, DGPF, JGAP, Watchmaker, Gen- Pro, GAlib, HeuristicLab, PyBrain, JCLEC, GPE, JGAlib, lutionary computation (frequently asked question in pycma, PyEvolve, GPLAB, Clojush, µGP, pySTEP, Pyvolu- the comp.ai.genetic Usenet newsgroup6) already tion, PISA, EvoJ, Galapagos, branecloud, JAGA, PMDGP, GPC++, PonyGE, Platypus, DCTG-GP, Desdeo, PonyGE2, 3Redacted by author’s demand. EvoGrad, HyperSpark, Nevergrad, Pagmo2, LEAP, Operon, 4http://geneura.ugr.es/~jmerelo/DegaX/ EMILI, pso-de-framework, MOACO. 5Which also supported ECJ. 8Libraries of solvers, like Pagmo2 or Nevergrad, do not 6Discussion forum which was popular before the World match this criterion. Wide Web and social networks. http://coast.cs.purdue. 9version 1.82 of https://github.com/AlDanial/cloc
2 are close competitors, albeit programmed in Java, patterns: Functor, Strategy, Generic Type and Fac- which is expected to run near 2.6 times slower than tory. Figure1 shows a high-level view of the global programs in C++10, a key drawback for automated design pattern. algorithm design (see Section 4.3). HeuristicLab suf- encoding:EOT fers from the same drawback, but provides a graphi- Interface cal user interface for the run and analysis of solvers. +operator()(args…)
Paradiseo does not provide such a GUI, but relies on :EOT OperatorSemantic dedicated third-party tools for this kind of function- +operator()(args…) ality (see [10] and Section 4.3). The other frameworks :EOT do not provide the same level of features and use lan- OperatorAggregate :EOT +parameters… guages that are generally slower than C++ [28]. Operator +operator: OperatorSemantic& +parameters… +operator()(args…) +operator()(args…) {manipulates any EOT} 2 Architecture Figure 1: UML diagram of a high-level view of the From its inception [29], Paradiseo opted for an original main design pattern used in the Paradiseo framework. architecture design, exemplified by its name, “Evolv- ing object”, as opposed to a procedural or functional view of the algorithm. In this section, we expose first Functor: In Paradiseo, most of the operators are the main concepts used in its architecture, to focus functions (exposing the operator() interface) next on the design patterns that have been used in it, holding a state between calls [32, 21]. Member giving it room for evolution and improvement along variables of the functors are either parameters the years. or references to other functors, involved in the computation. 2.1 Main Concepts Strategy: Operators can be composed to form an- The core of Paradiseo is formed by the EO module, other one. For instance, an eoAlgo is essentially which has been designed for general evolutionary al- an operator holding a loop which calls other gorithms. Most of its core concepts are used across operators. These operators must then honor the other modules and are named after its vocabu- an interface, which provides the semantic of lary: the underlying operation [14]. For instance, an eoSelectOne exposes the interface to pick a solu- Encoding: The data structure modelling a solution tion within a population: const EOT& operator()( to the optimization problem (which type is gen- const eoPop
2.2 Main Design Patterns Factory: As many operators are abstracted through their interfaces, Paradiseo provides ways to man- Paradiseo is a framework, providing a large set of com- age them as collections or high-level aggregates, ponents that the user can assemble to implement a so that the user does not have to manage the solver. To facilitate and enforce the design and use of details. For instance, Paradiseo provides clas- components, Paradiseo is based on four main design sical stopping criterion collections or on-the-fly instantiation (see also Section 4.3). 10Following the ”n-body” setup of the ”Computer Lan- guage Benchmarks Game”, which is the closest problem to our setting: https://benchmarksgame-team.pages.debian. With this approach, Paradiseo is enforcing the use of net/benchmarksgame/performance/nbody.html composition of objects, limiting the use of inheritance
3 to interfaces (generally of abstract classes). One of Generic encodings: Some solution representations the main goals of the framework is to be able to eas- which are often used when solving optimization ily compose new algorithms, by (i) reusing existing problems, like numerical vectors, binary vectors, common features (logging, parallelization, state seri- trees, permutations. alization, etc.) and (ii) assembling existing algorith- Parameters: An abstraction of parameters, which mic operators, for instance by hybridizing algorithms. can be used for command line interfaces, state Figure2 shows an example of the core concepts management and dynamic algorithms. which a user may see: the EO class, from which a solution to the optimization problem will inherit the Those features are generally used by the following interface necessary to be used across the operators, modules. and a set of operator interfaces and implementations, The EO module holds the following necessary which define an algorithm. classes to implement evolutionary algorithms, as il- lustrated in Figure3 (lower part): 3 Modules Selection: Operators which pick (a set of) solu- tions within a population. Two levels are avail- Paradiseo targets modular algorithms and is thus or- able: operators which pick a single solution ganized in several modules: Evolving Objects (EO) (eoSelectOne interface), and operators which se- for population-based algorithms such as evolutionary lect more than one solution (eoSelect). algorithms and particle swarm optimization, Moving Variation: Operators which generate new solutions Objects (MO) for local search algorithms and land- by altering existing ones. They are generally scape analysis, Estimation of Distribution Objects called “mutations”, when they alter a single so- (EDO) for estimation of distribution algorithms, and lution, and “crossover” when they alter two or Multi-Objective Evolving Objects (MOEO) for multi- more solutions at once. Both types return a objective optimization. Each module brings its own boolean which is true if an alteration has actually specific concepts and features, on top of the common been done. core features provided in the EO module. The follow- ing sections summarize this organization. Replacement: Operators which merge two popula- tions, typically “parents” with “offsprings” (pro- 3.1 Evolutionary and Particle Swarm duced by the alteration of parents with variation Algorithms — EO operators). The EO module defines a number of common opera- Algorithms: High-level operators which manipu- tors which are used across all the framework: late a population generated at initialization, and iteratively apply a set of operators until a stop- Evaluation of populations: Operators which call ping condition is satisfied. the objective function for a set of solution. With More information on the design of evolutionary algo- several parallelization options [7,6,4,5]. rithms within Paradiseo-EO can be found in [21]. Initialization: Operators which generate solutions, EO also defines classes which target particle swarm out of the optimization loop (generally at ran- optimization algorithms: dom). Particle: An interface on top of the EO class, which defines a freely moving particle. Continue: A stopping criterion which returns false if the iteration loop of an algorithm is to be Velocity: Operators which control the speed at stopped. which a particle is moving. Checkpoints: A generic operator which is called at Flight: Operators which control the next position at each iteration (for instance to collect statistics). which the particle will be. Updater: A generic operator which can update a parameter. 3.2 Local Search and Landscape Anal- ysis — MO State: A serialization of a state of an algorithm. The MO module adds an interface which can manage Wrappers: Operators which transform a (set of) op- single solutions instead of populations, mainly provid- erators as another one. ing a fine-grained level of abstraction, following the
4 encoding…:EOT… eoPrintable returns:bool +printOn(output:ostream) eo[U|B]F +operator()(args…:EOT): bool
eoObject eoPersistent +className(): string +readFrom(input:istream) :EOT :EOT scalar:T eo[Bin|Mon|Quad]Op eoAlgo comp:CMP eoDualFitness fitness:F +operator<(other:T): bool EO :EOT +fitness: F eoFastGA scalar:T +fitness(): F +_crossover: eoQuadOp comp:CMP +fitness(fitness:F) :EOT +_mutation: eoMonOp eoScalarFitness +invalidate() eoSelectOne +_select_cross: eoselectOne +invalid(): bool +_select_aftercross: eoSelectOne +operator<(other:T): bool +operator<(other:EO
:EOT eoPopEvalFunc +operator()(eoPop&,eoPop&): bool
Figure 2: General overview of the main classes involved in assembling one of the Paradiseo-EO algorithms. Concrete class implementations manipulated by the user are shown in dark gray. Interfaces which define generic behavior are figured in white. Low-level convenience classes provided by the framework are figured in light gray. same components as the EO module. It also adds the tain diversity in the population, seeking for well- important concept of incremental evaluation, to allow spread and uniformly-distributed solutions in the the design of objective functions which compute the objective space. value of a solution based on the application of a move to an already evaluated solution. The objective func- Selection: Operators which combine the ones above tion can thus take into account only the sub-parts of in order to guide the population towards Pareto- the solutions that have been altered, effectively im- optimal solutions. proving the computation time. Those operators are Archive: Secondary population which maintains tightly coupled with neighborhoods, which are varia- non-dominated solutions. tion operators applied to single solutions. The MO module additionally provides components Performance metrics: Quality indicators com- to sample the search space and estimate statistics for puted over populations or archives to measure characterizing the fitness landscape of the problem solution quality in multi-objective optimization. in terms of features, such as the density of states, the fitness distance correlation, the autocorrelation More information about the Paradiseo-MOEO mod- function, the length of adaptive walks, the landscape ule, and how to design multi-objective local search neutrality, or the fitness cloud [17, 11]. More infor- and evolutionary algorithms in Paradiseo are detailed mation about local search and landscape analysis in in [24]. Paradiseo-MO can be found in [18]. 3.4 Estimation of Distribution — 3.3 Multi-Objective Optimization — EDO MOEO The EDO module encompasses the features to man- The MOEO module adds the necessary features to age population-based algorithms which have an ex- handle multi-objective optimization [8, 35]: plicit state from which the population is derived at each iteration. Fitness assignment: Large set of operators which convert raw objective values into ranks or fitness Distribution: A template, wrapping the encoding values used for selection and replacement. They EOT and holding the data structure representing include state-of-the-art scalarizing-, dominance- a probability distribution. and indicator-based approaches. Estimator: Operators which compute distribution Diversity preservation: Operators which main- parameters from a given population.
5 Sampler: Operators which compute a population from a given distribution.
Several other operators allow to manipulate and com- bine those objects and to plug them within EO evo- lutionary algorithm’s variation operator, as shown on Figure3.
4 Key Features 4.1 Modular Algorithms The main feature of Paradiseo is to provide a large
olution set of modular algorithms, which are assembled from st s Be a large variety of operators. This is motivated by the fact that there exists a large diversity of optimization Stop. criteria? problems, which would be more efficiently solved by Modifier po pula tio Estimator n specific algorithms rather than generic ones. Distrib It is thus of prior importance to be able to easily ex- Sampler n plore the design space of algorithms, in order to find tio la u p o p the best one for a given problem. Having a large set of
Repairer reusable components is key to allow the practitioner to quickly try new algorithm variants, which may not have been tested yet. New ideas can also be experi-
ion solut mented with minimum effort, by allowing the user to st Be focus on a single (new) component. Figure4 shows
Stop. criteria? a simple example of a modular genetic algorithm (in- Estimator Distrib G en spired from [12]), which allows for the instantiation of Sampler ito Initialization rs s g n Selection ri p 1 630 475 different algorithm instances. In that case, s ff O
tion an algorithm instance is a combination of parameter- solu est B ized operators, with varying functions and/or param- Evaluation 11 Stop. criteria? eters . Of course, considering the whole footprint of
nts Pare Paradiseo would allow for far larger design space. Replacement It is also worth noting that the hybridization of two algorithms in Paradiseo is as simple as encapsulating Figure 3: Modular estimation of distribution algo- operators with a similar interface. For instance, it is rithm as seen from Paradiseo-EDO. The lower part of straightforward to use a local search algorithm imple- the diagram is the modular evolutionary algorithm mented with MO as a variation operator of an evolu- loop. EDO adds a set of operators to replace “im- tionary algorithm implemented with EO, then ending plicit” variation operator by “explicit” ones. The up with a so-called memetic algorithm. operators managing the probability distribution are Moreover, this modular architecture facilitates a shown in orange. fair comparison of algorithms in practical use cases, where wall-clock performance is of prior importance; e.g., for applications involving interactions with a hu- man. In such a case, having a common code base helps conducting more unbiased studies.
4.2 Fast Computations Paradiseo is one of the few optimization frameworks written in C++, a compiled programming language known for its runtime speed. Moreover, its design is
11Generally numerical or integer parameters, sometimes boolean or categorical ones.
6 <
eoSequentialSelect eoUBitXover 5 +preference = [0.1, 0.3,… 1[ 3 [0, 0.2, 0.4,…1] eoDetTournamentSelect 5 +tour_size = [2,6,… 11[ eoNPtsBitXover 5 +num_points = [1,3,… 10[ eoFastGA eoStochTournamentSelect 5 +rate_crossover: double +tour_rate = 0.5 5 <
eoStandardBitMutation eoNormalBitMutation +rate = 1 +rate = 1 eoSSGAWorseReplacement
eoConditionalBitMutation eoFastBitMutation 3 eoSSGAStochTournamentReplacement +rate = 1 +rate = 1 +tour_rate = [0.51,0.71,0.91]
5 eoSSGADetTournamentReplacement +tour_rate = [2,4,…11[
Figure 4: Example of relationships between an algorithm template (eoFastGA) and its related operators. Each package box groups alternative operators which may be used for the corresponding step of the algorithm. thought to directly plug components at compile time state disk, takes approximately 10 minutes with rather than relying exclusively on dynamically-run pycma/COCO, and only 1 minute with the Par- conditional expressions. adiseo/IOH implementation. A typical rationale in black-box optimization is to In addition, the Symmetric Multiprocessing mod- state that the efficiency of the algorithm computa- ule (SMP) allows to wrap any operator called within tions is not a concern, because in real cases the ob- a loop transparently to fully make use of CPU cores. jective function dominates the runtime. While this is The master-worker model has been shown to scale true in essence, this argument forgets that, during the (near) linearly with the number of cores, while having design phase of algorithms, practitioners most often a low communication overhead. SMP also provides a do not use complex objective functions, but synthetic parallel island model [34] that speeds up algorithm ones, which are very fast to compute. In that case, convergence while maintaining diversity. fast computation means fast design iterations. At last, we argue that fast computations of the al- For example, a CMA-ES algorithm imple- gorithm and objective function are necessary features mented with Paradiseo is 10 times faster than its to facilitate automated algorithm design, where an al- heavily optimized counterpart implemented with gorithm is itself in charge of finding the most appro- Python/Numpy, when solving a standard synthetic priate variant of an algorithm [22], learn what is the benchmark. Those measures are obtained using the best algorithm for a given benchmark [20], or even a reference implementation of CMA-ES available in given problem fitness landscape [23,3, 11]. In that the pycma package12, solving the Black-Box Opti- case, running an assembled algorithm on a bench- mization Benchmark (BBOB [15]) of the COmpar- mark is the objective function of the design prob- ing Continuous Optimizers (COCO13) platform [16]. lem, and its computation time determines the scale The Paradiseo implementation14 used the indepen- at which the experiment can be conducted. This fea- dent implementation of BBOB available on the ture is discussed in more detail below. IOHexperimenter15 platform [13]. Both benchmarks are implemented in C/C++. Running algorithms on the whole benchmark, on a single Intel Core 4.3 Automated Algorithm Design i5-7300HQ at 2.50GHz with a Crucial P1 solid- Automated algorithm design features are recent addi- 12Version 3.0.0 of https://github.com/CMA-ES/pycma tions to Paradiseo. They target the ability to assemble 13Version 2.3.2 of https://github.com/numbbo/coco algorithms at runtime without loss of performance, 14 Version 640fa31 of https://github.com/nojhan/ and easy bindings with benchmarking and algorithm paradiseo 15Version 2395af4 of https://github.com/nojhan/ selection tools. Figure5 shows the global setting, IOHexperimenter which is detailed in this section.
7 ParadisEO
<
+run() IOHexperimenter
IOH_ecdf_sum IOH_observer_combine +vector
IOH_logger <
Figure 5: Flow of information involved in automated algorithm design, starting with irace calling an exe- cutable interface (white box), to instantiate and run a Paradiseo algorithm (red boxes), which will call an IOHexperimenter problem (blue boxes) while being observed by a logger (green boxes). The final performance is computed (cyan box) and returned to irace.
On-the-fly Operator Instantiation with Foundries Foundries are “Factory” classes which allow to instantiate a parameterized operator, chosen among a set of operators having the same interface. The user can indicate which classes and parameters
should be managed and a foundry is responsible interface:Itf operator:Op parameters:Args… for instantiating when it is called with the index eoForgeOperator +parameters: tuple
solvers (i.e. generic hyper-parameters tuning). An :eoForgeInterface
vector :EOT algorithm foundry is thus a generic meta-algorithm, eoAlgo +operator()(eoPop
operator foundries rather than references to operator :EOT :EOT eoMyFoundry eoOperatorFoundry instances. Those operator foundries are responsible +selectors: eoOperatorFoundry
+operator()(eoPop
1 // Considering the FastGA modular algorithm , 2 // solvinga problem with fixed initialization. 3 auto& foundry = store.pack<
8 eoAlgoFoundryFastGA
9 9 std::cout <<"# name\t switch\t type\t among active frameworks. Practitioners can easily range\n"; design new algorithms which differ in some opera- 10 // We only need the parameter(s) and the tors, hybridize algorithms, or even add new algorithm foundry itself: 11 print_irace(mutation_rate_p, foundry. templates using existing operators. mutation_rates, Algorithm design: Paradiseo focuses on provid- 12 std::cout); ing a very large design space to the practitioner. 13 print_irace( crossover_p, foundry. crossovers , Thanks to its fast computations, large-scale design 14 std::cout); experiments can be addressed. Combined with its 15 // Any other operator within the foundry features dedicated to automation, Paradiseo algo- [...] rithm designers who want to test a new operator can 16 / This will output something like: ∗ easily focus on small code changes and rapidly check 17 # name switch type range 18 mutationrate” −−mutation−r a t e=”i (0,4) their efficiency and how they interact with other op- 19 c r o s s o v e r” −−c r o s s o v e r=”c erators in a given paradigm. Problem solvers can sort (0,1,2,3,4,5,6,7) out algorithm instances that work best. 20 [etc.] ∗/ As future works, we plan to improve the algorithm Listing 3: Excerpt of code for exposing a Paradiseo design automation features, merge more state-of-the- interface to irace. art modular designs, and enhance the overall user experience. With this setting, it has been possible to conduct One of the main impediments to a more widespread a large scale algorithm design study [2] , involving use of the framework is that the learning curve for irace configuring a FastGA algorithm family (cf. Fig- getting started is too steep. Solving this problem ure4) solving a W-model problem, using a budget of is the main objective of PyParadiseo, a module cur- approximately 1 billion function evaluations, in ap- rently under development, that will expose interfaces proximately 3 hours on a single core of a laptop (same to Paradiseo in Python, to facilitate the interoperabil- setup than Sec. 4.2). ity with external solvers, statistics program or ma- chine learning frameworks. 5 Conclusions
This article provides a high-level overview of the Par- Acknowledgments adiseo framework, a C++ free software which tar- During 22 years, Paradiseo has been developed by gets the development of modular metaheuristics. The more than 50 people, with the support of the fol- main feature of Paradiseo is its ability to help practi- lowing institutions: Inria, University of Lille, Univer- tioners to focus on creating solvers while thinking at sity of the Littoral Opal Coast, Thales, Ecole´ Poly- a higher level of abstraction, thanks to: technique, University of Granada, Vrije Universiteit Utility features: Paradiseo provides a large set of Amsterdam, Leiden University, French National Cen- engineering features, which very often lack in proof- tre for Scientific Research (CNRS), French National of-concept frameworks: several fine-grained paral- Agency for Research (ANR), Fritz Haber Institute lelization options, convenient interface features (com- of the Max Planck Society, Center for Free-Electron mand line argument parsing, state management, use- Laser Science, University of Angers, French National ful logs, etc.). Having robust implementation of such Institute of Applied Sciences, Free University of Brus- features is often overlooked by users focusing on the sels, Pasteur Institute. algorithmic part. Component-based architecture: The concept of operator is at the core of the design of Paradiseo. References It allows for the composition of algorithms, with- out the overhead of a dynamically loading plugins [1] Maribel Garc´ıa Arenas, Brad Dolin, Juan or the rigidity of a monolithic structure. Solvers be- Juli´an Merelo Guerv´os, Pedro Angel´ Castillo ing assembled as a selection of components are also Valdivieso, Ignacio Fern´andez De Viana, and lightweight, as it is not necessary to build and carry Marc Schoenauer. Jeo: Java evolving objects. all the framework’s code within the executable bina- In GECCO, volume 2, pages 991–994, 2002. ries. Modular algorithm models: Paradiseo pro- [2] Amine Aziz-Alaoui, Carola Doerr, and Johann vides several modules targeting different algorithm Dreo. Towards Large Scale Automated Algo- paradigms —probably one of the largest footprints rithm Design by Integrating Modular Bench-
10 marking Frameworks. In Proceedings Companion [11] Bilel Derbel and S´ebastien Verel. Fitness of the Annual Conference on Genetic and Evo- landscape analysis to understand and predict lutionary Computation, GECCO’21. to appear, algorithm performance for single- and multi- 2021. objective optimization. In Carlos Artemio Coello Coello, editor, GECCO ’20: Genetic and Evo- [3] Nacim Belkhir, Johann Dreo, Pierre Sav´eant, lutionary Computation Conference, Companion and Marc Schoenauer. Per instance algorithm Volume, Canc´un,Mexico, July 8-12, 2020, pages configuration of cma-es with limited budget. 993–1042. ACM, 2020. In Proceedings of the Genetic and Evolutionary Computation Conference, pages 681–688, 2017. [12] Benjamin Doerr, Carola Doerr, and Franziska Ebel. Lessons from the black-box: Fast [4] S´ebastien Cahon, Nordine Melab, and E.-G. crossover-based genetic algorithms. In Proceed- Talbi. Building with paradiseo reusable parallel ings of the 15th annual conference on Genetic and distributed evolutionary algorithms. Paral- and evolutionary computation, pages 781–788, lel Computing, 30(5–6):677–697, 2004. 2013.
[5] S´ebastien Cahon, Nordine Melab, and E-G [13] Carola Doerr, Hao Wang, Furong Ye, Sander van Talbi. Paradiseo: A framework for the reusable Rijn, and Thomas B¨ack. IOHprofiler: A Bench- design of parallel and distributed metaheuristics. marking and Profiling Tool for Iterative Opti- Journal of heuristics, 10(3):357–380, 2004. mization Heuristics. arXiv: 1810.05281. [6] S´ebastien Cahon, Nordine Melab, E-G Talbi, [14] Erich Gamma, Richard Helm, Ralph E. Johnson, and Marc Schoenauer. Paradiseo-based design of and John Vlissides. Design patterns: elements parallel and distributed evolutionary algorithms. of reusable object-oriented software. Addison- In International Conference on Artificial Evo- Wesley, 1995. lution (Evolution Artificielle), pages 216–228. Springer, 2003. [15] Nikolaus Hansen, Anne Auger, Raymond Ros, Steffen Finck, and Petr Poˇs´ık.Comparing results [7] S´ebastien Cahon, E-G Talbi, and Nordine of 31 algorithms from the black-box optimiza- Melab. Paradiseo: a framework for paral- tion benchmarking bbob-2009. In Proceedings of lel and distributed biologically inspired heuris- the 12th Annual Conference Companion on Ge- tics. In Proceedings International Parallel and netic and Evolutionary Computation, GECCO Distributed Processing Symposium, pages 9–pp. ’10, page 1689–1696, New York, NY, USA, 2010. IEEE, 2003. Association for Computing Machinery. [8] C. A. Coello Coello, G. B. Lamont, and [16] Nikolaus Hansen, Anne Auger, Raymond Ros, D. A. Van Veldhuizen. Evolutionary Algorithms Olaf Mersmann, Tea Tuˇsar,and Dimo Brockhoff. for Solving Multi-Objective Problems. Genetic COCO: a platform for comparing continuous op- and Evolutionary Computation Series. Springer, timizers in a black-box setting. 36(1):114–144. New York, USA, second edition, 2007. [17] H. Hoos and T. St¨utzle. Stochastic Local Search: [9] Pierre Collet, Evelyne Lutton, Marc Schoe- Foundations and Applications. Morgan Kauf- nauer, and Jean Louchet. Take It EASEA. mann, San Francisco, CA, USA, 2004. In Marc Schoenauer, Kalyanmoy Deb, G¨unther Rudolph, Xin Yao, Evelyne Lutton, Juan Julian [18] J´er´emieHumeau, Arnaud Liefooghe, E-G Talbi, Merelo, and Hans-Paul Schwefel, editors, Paral- and S´ebastienVerel. Paradiseo-mo: From fitness lel Problem Solving from Nature PPSN VI, Lec- landscape analysis to efficient local search al- ture Notes in Computer Science, pages 891–901. gorithms. Journal of Heuristics, 19(6):881–915, Springer. 2013.
[10] Pierre Collet and Marc Schoenauer. GUIDE: [19] Robert Hundt. Loop Recognition in Unifying Evolutionary Engines through a C++/Java/Go/Scala. In Proceedings of Graphical User Interface. In Pierre Liardet, Scala Days 2011. Pierre Collet, Cyril Fonlupt, Evelyne Lutton, and Marc Schoenauer, editors, Artificial Evolu- [20] Frank Hutter, Youssef Hamadi, Holger H. Hoos, tion, Lecture Notes in Computer Science, pages and Kevin Leyton-Brown. Performance Pre- 203–215. Springer. diction and Automated Tuning of Randomized
11 and Parametric Algorithms. In Fr´ed´ericBen- for evolutionary algorithm operations. In Euro- hamou, editor, Principles and Practice of Con- pean Conference on the Applications of Evolu- straint Programming - CP 2006, Lecture Notes tionary Computation, pages 689–704. Springer, in Computer Science, pages 213–228. Springer. 2017.
[21] Maarten Keijzer, Juan J Merelo, Gustavo [29] Juan-Juli´an Merelo-Guerv´os, M. G. Arenas, Romero, and Marc Schoenauer. Evolving ob- J. Carpio, P. Castillo, V. M. Rivas, G. Romero, jects: A general purpose evolutionary computa- and M. Schoenauer. Evolving objects. In P. P. tion library. In International Conference on Ar- Wang, editor, Proc. JCIS 2000 (Joint Confer- tificial Evolution (Evolution Artificielle), pages ence on Information Sciences), volume I, pages 231–242. Springer, 2001. 1083–1086, 2000. ISBN: 0-9643456-9-2. [30] Sergio Nesmachnow, Francisco Luna, and En- [22] Pascal Kerschke, Holger H. Hoos, Frank Neu- rique Alba. An empirical time analysis of evo- mann, and Heike Trautmann. Automated Al- lutionary algorithms as c programs. Software: gorithm Selection: Survey and Perspectives. Practice and Experience, 45(1):111–142, 2015. 27(1):3–45. [31] I. Rechenberg. Cybernetic Solution Path of an [23] Kevin Leyton-Brown, Eugene Nudelman, and Experimental Problem. Yoav Shoham. Learning the Empirical Hardness of Optimization Problems: The Case of Combi- [32] David Vandevoorde and Nicolai M. Josuttis. natorial Auctions. In Pascal Van Hentenryck, ed- C++ template: the complete guide. Addison- itor, Principles and Practice of Constraint Pro- Wesley. gramming - CP 2002, Lecture Notes in Com- [33] S. Wagner, G. Kronberger, A. Beham, M. Kom- puter Science, pages 556–572. Springer. menda, A. Scheibenpflug, E. Pitzer, S. Vonolfen, [24] Arnaud Liefooghe, Laetitia Jourdan, and El- M. Kofler, S. Winkler, V. Dorfer, and M. Affen- Ghazali Talbi. A software framework based zeller. Architecture and Design of the Heuris- on a conceptual unified model for evolution- ticLab Optimization Environment. Topics in ary multiobjective optimization: Paradiseo- Intelligent Engineering and Informatics, pages moeo. European Journal of Operational Re- 197–261. Springer International Publishing. search, 209(2):104–112, 2011. [34] Darrell Whitley, Soraya Rana, and Robert B Heckendorn. The island model genetic algo- [25] Manuel L´opez-Ib´a˜nez,J´er´emieDubois-Lacoste, rithm: On separability, population size and con- Leslie P´erez C´aceres, Mauro Birattari, and vergence. Journal of computing and information Thomas St¨utzle. The irace package: Iterated technology, 7(1):33–47, 1999. racing for automatic algorithm configuration. Operations Research Perspectives, 3:43–58, 2016. [35] E. Zitzler, M. Laumanns, and S. Bleuler. A tuto- rial on evolutionary multiobjective optimization. [26] Ogier Maitre, Fr´ed´ericKr¨uger,St´ephaneQuerry, chapter 1, pages 3–38. Springer Science & Busi- Nicolas Lachiche, and Pierre Collet. EASEA: ness Media. specification and execution of evolutionary algo- rithms on GPGPU. 16(2):261–279.
[27] Nouredine Melab, Th´eVan Luong, Karima Bou- faras, and El-Ghazali Talbi. Paradiseo-mo-gpu: a framework for parallel gpu-based local search metaheuristics. In Proceedings of the 15th annual conference on Genetic and evolutionary compu- tation, pages 1189–1196, 2013.
[28] Juan-Juli´an Merelo-Guerv´os, Israel Blancas- Alvarez,´ Pedro A Castillo, Gustavo Romero, Pablo Garc´ıa-S´anchez, V´ıctor M Rivas, Mario Garc´ıa-Valdez, Amaury Hern´andez-Aguila,´ and Mario Rom´an.Ranking programming languages
12