A Distributed Object-Oriented Genetic Programming ... - CiteSeerX

PMDGP: A Distributed Object-Oriented Genetic Programming Environment Pieter G.M. van der Meulen, Han Schipper, Asker M. Bazen ∗ and Sabih H. Gerez University of Twente, Department of Electrical Engineering, Laboratory of Signals and Systems, P.O. box 217 - 7500 AE Enschede - The Netherlands Phone: +31 53 489 3827 Fax: +31 53 489 1060 [email protected] Keywords: genetic programming, genetic programming environment, distributed processing, fingerprints, minutiae extraction, image exploring agents.

Abstract

power can be achieved by using a suitable parallel architecture. In order to keep the highest level of flexibility, we have chosen to parallelize fitness evaluation instead of the more easily implementable deme structure, which is discussed in Section 5. The advantages of this solution are that it does not restrict the GP algorithm and that it can use the idle computing time in a heterogeneous computing environment that consists for instance of Unix workstations and WinNT and Linux PCs. This paper will present the considerations related to an efficient implementation of such an environment as well as experimental results. Our GP environment, which is also briefly described in [6], is called Poor Man’s Distributed Genetic Programming (PMDGP), as it is designed to make use of existing heterogeneous hardware rather than expensive hardware that has to be purchased for the purpose of GP. The rest of this paper is structured as follows. First, Section 2 provides an introduction to genetic programming and Section 3 discusses some general requirements we have for a GP environment. Section 4 describes the representation of the individuals and Section 5 discusses the possibilities for distribution of a GP system. Then, Section 6 discusses some relevant implementation details of the framework. Finally, Section 7 illustrates the use and performance of the GP framework by applying it to the evolution of an agent for minutiae extraction from fingerprints.

In this paper, an environment for using genetic programming is presented. Although not restricted to a specific domain, our intention is to apply it to image processing problems such as fingerprint recognition. The environment performs tasks like: population management, genetic operators and distributed parallel evaluation of the programs. Furthermore, it provides a framework for implementation of the problemspecific part. Using object-oriented methods, the environment is designed to offer a high degree of flexibility and ease of use. The GP environment uses distributed fitness evaluation, which can be used on existing computer networks. The system is optimized for efficiency of distribution. Experiments are included in the paper to illustrate the high performance of our implementation of this distribution method.

1

Introduction

Genetic programming (GP) [1, 2, 3] is a method to automatically search for computer programs that perform a specific task. In this paper, an environment for using genetic programming is presented. Although not restricted to a specific domain, our intention is to apply it to image processing problems such as fingerprint recognition [4]. The environment is designed to efficiently perform the problem-independent tasks. Furthermore, it provides a framework for the implementation of the problem-specific tasks. Solving realistic problems with GP may consume up to 1016 clock cycles [5]. This amount of computer

2

This section provides an introduction to genetic programming (GP) [1, 2, 3]. GP is a method to automatically search for computer programs that perform a specific task. It is, among for instance neural net-

∗ author to address all correspondence to

1 7th Annual Conference of the Advanced School for Computing and Imaging, May 30 - June 1, 2001, Heijen, The Netherlands.

Genetic Programming

works, fuzzy logic and genetic algorithms, one of the computational intelligence (CI) methods. CI is used for a collection of problem-solving techniques that are inspired by nature. GP works with a population of individuals: programs that can possibly solve the given problem. The first generation of this population is created randomly. Then, all programs are evaluated by applying them to typical problem instances. This results in a fitness measure being assigned to each program. The programs that have the highest fitness, have the highest probability to participate in the creation of the next generation. This process repeats until a satisfactory solution is found or a fixed number of generations is reached. This process is described in more details in the next subsections.

2.1

results, since it creates the most diverse population. The method creates a individuals of various depths and half of the population is fully initialized and the other half is grown.

2.3 Fitness Each individual has to be evaluated by applying it to certain test situations. How well the individual solves the problem is expressed in a fitness value. According to this value, candidate solutions are selected that will contribute to the next generation. The selection mechanism will make the better quality solutions survive from generation to generation, while the inferior solutions are eliminated.

2.4 Genetic Operators

Individuals

Once a fitness value is assigned to all individuals, a new generation is evolved. New individuals are constructed from the selected individuals by three different genetic operators:

The representation of the programs has to be chosen carefully. The individuals must use a representation that works well with genetic operators like crossover and mutation. This is guaranteed by using closure, which means that the output of each node, which is a basic building block for the programs, can be used as the input of any other node. Then, each new individual encodes a legal solution. Furthermore, the representation must be able to efficiently represent important programming concepts like conditional execution, loops and subroutines. To deal with these constraints, programs are represented by tree-like expressions, which is for the program b2 −4ac shown in Figure 1(a). Constructing offspring using crossover between parents, described in Subsection 2.4, then amounts to exchanging branches from the parents. Alternatively, the same program can be given in prefix code by (- (* b b) (* 4 (* a c))), which is shown in Figure 1(b).

2.2

• reproduction selects a individual and passes it unchanged to the next generation; • crossover selects two parent individuals, and combines fragments of them, resulting in two new offspring individuals; • mutation selects an individual, imposes a small random change on it, and then passes it to the next generation. The new individuals of the next generation may or may not represent an improved solution. However, the average fitness and best fitness will in general increase in each generation.

3

Initial Population

From all new GP systems that are being developed in Java, it can be concluded that there is a huge need for flexible GP systems in which any GP problem is easily implemented. However, we believe that flexibility is not the only requirement for a useful GP environment. Since solving realistic problems with GP requires a lot of processing power, the environment should be highly efficient as well. Of course, these two requirements are somewhat contradictory. This section further specifies our requirements to a GP environment. At the same time, it provides a motivation why we did not choose to use one of the available environments, but decided to design an environment ourselves instead.

The GP process starts by creating an initial population, containing a number of randomly created individuals. All individuals are subject to some constraints, like a maximum depth and a maximum number of nodes. Several methods of creating the initial population exist. When constructing an individual, one starts with the top-level node and repetitively adds nodes to its inputs. Adding a terminal node terminates the construction of that branch. Adding a function node forces the construction of a new level. The full initialization creates trees of a given depth that only contains terminal nodes at that depth level. On the other hand, the grow initialization creates a tree by randomly choosing between a function and a terminal, until the maximum depth is reached. In general, a ramped half-half initialization shows the best

• The system should support all possible extensions to GP. If they are not already included in the environment, it should be simple to include them, without redesigning the entire system. 2

7th Annual Conference of the Advanced School for Computing and Imaging, May 30 - June 1, 2001, Heijen, The Netherlands.

Requirements for a Genetic Programming Environment

• The system should not only be limited to support the data structures representing the individuals and the genetic operators. It should also handle the evaluation of the individuals. • The system should be extensively configurable without the need for recompilation. This is important, since the best configuration is highly dependent on the problem considered. In general, several experiments have to be performed before a suitable configuration can be set. • The evaluation of the individuals should be highly efficient. As discussed in Section 4, the system should use some kind of prefix coding for the individuals instead of trees of pointers. Furthermore, it is not possible to design such an efficient system in Java, as explained in Section 6. • The system should support distribution of the GP process, as discussed in Section 5. If possible, it should be able to use idle computation time in a multi-platform heterogeneous computer environment. Furthermore, the system should handle distribution entirely by itself. The user should not have to write code that is specific to distribution. Instead, the distribution should be completely transparent to the user.

2

* b b * 4 * a c

Node list:

b

-

* b

4

* a

(a) Tree

c

* 4 a b c

(b) Prefix

Figure 1: Representation of individuals by means of a tree structure and prefix code implementation by means of a node list. the tree structure implicitly in a linear data structure. This is important when individuals have to be sent over the network in a distributed system. Unlike pointer trees, this representation does not have to be rebuilt once received over the network, since pointers are defined in the address space of the local machines. The prefix code of our system is based on the prefix jump table [16]. In this method, all nodes are represented by an index in a jump table. This jump table contains pointers to the functions to call. In our system, the jump table is replaced by a node list, containing references to the code of all nodes that are used in the population. This is illustrated in Figure 1(b). Tokens are used as reference to the nodes instead of indices in the jump table, as discussed below. Since all different nodes are derived from one abstract base class, polymorphism is used for addressing the nodes, instead of pointers to functions. Throughout the system, two different representations are used, which are at some points in the system translated into each other. • During evaluation of the individuals, a program is coded by pointers to nodes. This representation takes 4 bytes per node on most systems, which is the size of a pointer. This method provides the most efficient evaluation, since it uses one indirection less than the method that uses indices in a jump table. • The code that is sent over the network to the clients uses indices in the node list. This code needs only 1 or 2 bytes per node, depending on the number of different nodes in the node list. Since each different random constant takes one node, this representation usually consumes up to 2 bytes per node.

Representation of the Individuals

There are two requirements to the representation of the individuals in a high performance distributed GP environment. First, the individuals should be evaluated very efficiently and, second, the data that is sent over the network has to be very small. The system uses prefix code for the storage of individuals. The logical structure of the individuals is a tree structure, as shown in Figure 1(a). However, this does not imply that they should be stored as pointer trees. Although the genetic operators are a little harder to implement, prefix code allows much more efficient evaluation of the individuals and has much lower memory requirements. Prefix code stores

The translation of one representation into the other is performed at sending and reception of the programs between the clients and the server. Using this implementation, nodes may contain their own data. This is especially useful for constants. Random constants can be used by creating random constant nodes during the creation of the initial popu3


-

*

Many GP environments are available on the Internet. Examples of available systems that are implemented in C or C++ are: GPC++ [7], GPK [8], lil-gp [9], GPData [10]. Examples of systems that are implemented in Java are: EJC [11], GPSys [12], JGProg [13]. Furthermore, two distributed environments are available: parallel lil-gp [14] in C and DGP [15] in Java. Using the three basic requirements, being ‘implemented in C/C++’, ‘prefix coding’ and ‘distributed processing’, leaves us with only one system being parallel lil-gp. However, this system uses demes, which is not an attractive solution in a heterogeneous network, as discussed in Section 5, and it is not very flexible. Therefore, we have chosen to design a GP environment ourselves.

4

Prefix coded program: b -4ac

-

lation. Furthermore, variables, world information and memory can be implemented easily.

5

is not easy in a heterogeneous computer environment. Especially when using idle time, huge differences in computational power will exist between the processors. parallel fitness evaluation does not exclude the functional use of demes. This can be easily implemented by writing a new version of the genetic algorithm that maintains separate subpopulations. The disadvantage of this implementation is that each individual has to be sent over the network for fitness evaluation, rather than of only the migrating individuals as in a genuine deme implementation. The computer configuration for distributed fitness evaluation consists of one server and multiple clients, all situated on a single local area network. The server manages the population. It applies the genetic operators and sends the individuals to the clients which perform the fitness evaluation. This process is completely transparent to the user. Since the clients only have to evaluate one single individual at a time, their memory requirements are low. During the initialization, each client reports its availability to the server. At the start of a run, the server sends the evaluator (discussed in Section 6), the node list (discussed in Section 4) and the configuration settings to each client, after which the client starts its evaluator process. During a run, the server distributes the individuals among the clients. The clients evaluate them and return the resulting fitness values to the server. Then, the server uses this information to evolve the next generation. The system uses client driven scheduling. The scheduling of the distribution is performed by the clients, which buffer the individuals and ask the server for new individuals whenever needed. Cross platform code is achieved by the use of wxWindows [19]. This is a set of libraries that allows C++ applications to compile and run on several different types of computer. It provides a common API for GUI functionality and commonly-used operating system facilities, like file access, socket and thread support. For distributed fitness evaluation, minimizing the communication overhead of a GP system is a critical design issue. If no sufficient care is taken, too much overhead can undo the advantages of distributed processing. In fact, communication considerations have strongly influenced the design of the entire PMDGP system, resulting in the fact that three kinds of information have to be sent over the network:

Distributing GP

The application of GP to realistic problems may take a lot of computational time. Therefore, it is highly recommended to use a distributed GP system [5]. There are three ways in which GP can be distributed: • Parallel runs. In general, GP will not yield a good solution in each run. Therefore, a number of runs are needed in order to find a good solution. An obvious way of distributing GP is to execute these runs at the same time on different computers. However, this solution does not offer most of the advantages of real distribution. For instance, it does not speed up the execution of a single run. • Demes. Demes are sub-populations that run at the same time, possibly on different computers. After each generation, a percentage of the individuals migrates to the neighboring demes. The use of demes is the most widely used method of distributing GP. However, for good results it requires all computers to run at approximately the same speed. This is not realistic in case of a heterogeneous computer environment and the use of idle time is not possible at all. Furthermore, the efficiency of this method it is still a topic of discussion [17]. • Parallel fitness evaluation. The most flexible way of distributing GP is to use parallel fitness evaluation. In this method, the population is managed on a single machine, while individuals are sent to several computers for the fitness evaluation. In this way, the inherent parallelism of GP is exploited, without imposing any restrictions. The large number of individuals and the relatively small amount of time it takes to evaluate one single individual allows for relative fine-grain scheduling. Therefore, this approach is well-suited to a heterogeneous computer environment and allows the use of idle time. In case of a dedicated computer system, consisting of a number of equal processors, is available, it is generally agreed that the use of demes is the optimal distribution method, both in efficiency as well as in ease of implementation of the system. Given the fact that dedicated systems, like the 1000 node 350 MHz Pentium III Beowulf cluster of Koza [18], are not within the reach of everybody, the next best method is to use computers in existing networks and take advantage of idle time. In order to achieve this, we have chosen to use parallel fitness evaluation as the method of distribution. Even if the use of demes would be more efficient, it

• At the start of a run, the evaluator initialization and the node list are sent to all clients. This large piece of data has to be sent only once. • During the run, the prefix coded programs, requiring only 1 or 2 bytes per node have to be transferred over the network. The size of this code is minimized. 4


Server

Client

initialization stream

nodelist

program population

client. The client unpacks them, evaluates them and sends back the fitness values.

evaluator

genetic algorithm

coder

packed

packed

decoder

program evaluator nodelist

programs fitness value streams during run

Figure 2: Software structure of the PMDGP system. • After evaluation, the fitness value, which is just a scalar, is the only information that has to be returned to the server. •

By minimizing the communication during the run, which is given by the second and third items, a low overhead ratio is achieved, at the cost of more communication during the initialization.

6

Design Details

This section discusses some details of the genetic programming environment as we implemented it. The system fulfills all requirements as specified in the previous sections. This section does not provide a complete description of the system. Instead, it discusses the issues which we think are important.

•

• The system is implemented in C++. This language is object oriented and enables the use of polymorphism, which enables a very flexible system and enables the re-use of parts of the code. Furthermore, compilers for C++ are available for any platform, which is a requirement for a cross-platform system. Finally, the STL part of the C++ standard library provides powerful containers and algorithms, resulting in very efficient code.

•

The advantage of the use of Java is that it is meant as a cross platform language in which it is, for instance, very easy to send objects over a network. However, this ease of use is achieved at the cost of some loss of efficiency. For instance, some overhead is added to all objects. This overhead is in the order of a couple of bytes per object. Since in a distributed GP system many objects are in memory and have to be transferred over the network, this results in a high degree of overhead. For this reason, we have chosen not to use Java. • We have chosen for a highly modular or component-based design. Part of it is visualized in Figure 6. In this figure, the server is depicted on the left and a client on the right. During the initialization, the server sends the evaluator to the clients. During the run, the coder of the server translates individuals from the population into the 2-byte index representation and sends them to the

•

•


In order to achieve flexibility and reconfigurability, the genetic algorithm is split into a number of parts, like the population manager, the initializer, the fitness evaluator, the fitness scaler, the selector, the crossover operator, the mutator, etc. All the parts are implemented as an abstract base class, from which classes are derived which contain the implementations. Some predefined versions of these parts come with the framework, but users are encouraged to write their own implementations as well. In that case, the abstract base class provides a starting point, from which new versions are implemented easily. As a result of the previous item, the implementation of some ‘difficult’ parts of the environment is strictly separated from the application-specific user code. An important part of the design is the interpreter of the prefix codes: the environment carries out the execution of individuals. When a user is satisfied with the standard implementations of the GA, the user is only a client-programmer who has to write the problem-specific parts: the code for new types of nodes and code for computation of the fitness of the individuals. This is illustrated in the minutiae detection example of Section 7. The system is fully configurable without the need for recompilation, which is important when searching for the right settings for a given problem. All parameters, describing the objects in the system and the configuration settings, are set in one single text file. The system is designed in a strictly modular way, allowing to select the nodes, genetic operators, evaluator, etc. as part of the configuration settings. The design of the base class of nodes is very general. This way, nodes may contain their own data like random constants or represent automatically defined functions (ADFs), which are subroutines that evolve simultaneously with the main program, as well. The results of a run are reproducible. We have implemented our own random generator, which is initialized by a seed value. Therefore, it will produce the same results on any computer for the same seed value. Furthermore, the seed value is sent along when distributing the individuals, which is for instance used when randomly selecting fitness cases. This way, the distribution will not influence the results of a run for a given seed value. All data that is passed between the nodes, is of a type result, which is implemented in a result class. This enables the simple use of more complex data types like vector or matrix by defining a new result class. This is a very flexible way for the implementation of the data passing between nodes,

7.1 Problem Definition

which enables the reuse of code. If, for instance, the operator + is defined for a new result class, the standard add node can be used, since the result class is used as a template for the nodes. • The prefix code is evaluated recursively. Therefore, there is no central program counter, and the evaluation cannot be stopped from a central position in the code. To prevent each node from checking a certain flag for determining whether to stop the evaluation or not, the C++ exception mechanism can be used to break from the programs. This way, a clean and efficient way of breaking, including for instance stack unwinding etc. is achieved. An example of the use of this feature is the ‘ant’ problem [1], which has to stop after a certain number of moves. • For visualization of solutions that certain individuals provide, a trace function has been written. Two obvious solutions to this problem exist. In the first solution, for each node, the user also writes a node that does not only execute, but also performs some kind of visualization. The second solution is to write nodes that check if they have to take some visualization action. However, the first solution is not very user friendly, while the second solution has performance impact on the normal evaluation of nodes. As an alternative solution, our trace function automatically replaces all nodes by trace-nodes in case visualization is needed. The trace-nodes first execute the corresponding node and then perform the visualization.

A well known problem in fingerprint recognition is the detection of minutiae. A fingerprint is characterized by its ridge-valley structures, which are the lines in a fingerprint. The minutiae are the endpoints and bifurcations of the ridges. This problem focuses on detecting endpoints. The goal of this problem is to let GP develop an image exploring agent (IEA) [20]. An IEA walks through a picture by continuously repeating its program and will terminate when it has found a region of interest (ROI). In this case the ROI is a ridge ending. So when an IEA is placed on a ridge of the fingerprint, it should follow that ridge until it finds an endpoint of that ridge. This problem is well suited for a learning algorithm like GP, because it can be trained by manually marking the endpoints. During training all GP programs are evaluated on two different fingerprints. On each fingerprint five endpoints have been marked. For each endpoint two starting points have been marked. So each program is tested with 20 searches for endpoints. The maximum number of generations is 50 and each generation consists of a population of 5000 genes. This process takes a lot of processing time, so parallelism can be used well. The fitness value of a program is calculated by summing the 20 distances between the manually marked endpoints on the pictures and the position where the IEA terminates. An IEA normally consists of three parts, being a sense part, which looks in the local neighborhood of the agent, a compute part, that processes the information and an act part that lets the agent perform an action. The configuration for the GP program consists of two function sets. The first is the main function set, that performs the sense/compute part. Its nodes are: IfThen, Progn, I1x1, I3x3, Var3x3, HorEdge, VertEdge, ADF1. The function IfThen has four arguments. It compares its first two arguments. If the first argument is larger than the second argument, the third argument is executed else the fourth argument is executed. Progn executes two arguments and returns the result of its last argument. The other functions in the main function set extract information from the picture. HorEdge and VertEdge are simple edge detectors, while I1x1, I3x3 and Var3x3 take the average intensity or variance in some area. ADF1 calls the ADF. The ADF consists of the following function set: Progn, MoveD, MoveL, MoveDF, MoveAntiDF, End and it takes one argument. The ADF is the act part of the agent. It can move to the darkest or lightest pixel (MoveD, MoveL) in the neighborhood and it can follow the local directional field (MoveDF, MoveAntiDF), which is the local orientation of a

We believe that these design choices, together with the methods discussed in Sections 4 and 5, results in a very efficient and flexible GP environment.

7

Experiments

This section provides some experimental results, obtained from our GP environment. In this section, we use an example from fingerprint recognition as benchmark. In this problem, an agent is evolved that has to find the endpoints of ridges in a fingerprint. This problem is very illustrative for demonstrating the capabilities of GP. Furthermore, since it is a relatively simple problem that requires considerable computational power for its evaluation, it is well suited to illustrate the performance of the distributed fitness evaluation. First, Subsection 7.1 describes the minutiae detection problem. This section illustrates the flexibility of the system by showing how to implement this problem in our GP environment. Then, in Subsection 7.2, the performance of distributing the fitness evaluation is analyzed, by means of experiments with various computer configurations. 6


Table 1: Computers used in our distribution performance experiments. Type Clock Time Speed IDs 1, 2, 3 P-II 266 MHz 1515 sec. 1.00 4, 5 P-III 500 MHz 848 sec. 1.79 6, 7 P-III 800 MHz 493 sec. 3.60

Config 1 1-2 1-3 1-4 1-5 1-6 1-7

Figure 3: Path of the agent, which follows the ridge upwards and stops at the endpoint. ridge. It also has an End node for terminating. When the agent does not move for more than one cycle of its program, it is automatically terminated, because otherwise it will stay in that position forever. The best individual of a certain run has a raw fitness of 21. This means that the agents terminate on average only 1.05 pixel from the marked endpoints. This individual is given by: main: (IfThen HorEdge I1x1 (ADF1 (IfThen HorEdge Var3x3 Var3x3 I1x1)) HorEdge) ADF1: (Progn (Progn (Progn MoveDF V7) (Progn MoveDF V7)) (Progn MoveDF (Progn (Progn V7 MoveDF) MoveDF))) V7 is the argument that is given to the ADF from the main function set. It can be seen that this program mainly follows the directional field and does not move when it detects an ending. However this simple approach gives good results, as can be seen in Figure 3.

7.2

on this configuration takes 1570 seconds, which corresponds to a relative speed and scaling of 0.96. Next, the experiment is performed on various other computer configurations, where the number of participating computers is subsequently increased by one, on a 100 MBit LAN. In order to get the cleanest scaling figures, an additional 266 MHz P-II, is used as a dedicated server. Again, the experimental processing times are normalized with respect to the experiment on the reference computer, and the scaling factor is calculated. The results of this experiment are given in Table 2 and Figure 7.2. From the table, it can be seen that the scaling factor decreases when more computers are used in parallel. There are several reasons for this fact. First, some overhead is introduced in distributing the fitness evaluation. Some time is spent in the coding and decoding of individuals and in network communication. Furthermore, all clients are waiting while the server is evolving the next generation. Furthermore, due to the scheduling method used, clients perform some double work at the end of a generation. However, the main bottleneck is the throughput of the server. This problem could be solved by using a faster computer for this task or by using a larger packet size. The scalability of this method of distributing GP is very dependent on the nature of problem that is

Distribution Performance

In this subsection, the distribution performance is analyzed by running the minutiae detection problem on a number of different computer configurations. At the moment, the Windows NT and 9x version is used. Although, the code is written in a portable way, using wxWindows for GUI and network support, a Unix version is not yet available. First, the problem has been executed in singleprocess mode on the selected computers. The speeds of these computers are normalized with respect to Computer 1, which is the reference. The results of this test are summarized in Table 1. For a run in single-processor mode on the reference computer, a run of 50 generations with a population size of 5000 individuals takes 1500 seconds. In order to evaluate the performance of the distribution method, the experiment is first performed on a server-client configuration on the reference computer. Since communication has to be done using network protocols and all individuals have to be packed and unpacked, this will introduce some overhead. A run

15

10

5

0 0

5

10

15

Figure 4: Distribution performance. 7


Table 2: Distribution results Time Speed Ideal Scaling 1517 sec. 1.00 1.00 1.00 765 sec. 1.98 2.00 0.99 525 sec. 2.89 3.00 0.96 333 sec. 4.55 4.79 0.95 255 sec. 5.94 6.58 0.90 184 sec. 8.23 10.18 0.81 147 sec. 10.31 13.78 0.75

solved. The performance that we found in this section, cannot be assumed for any GP problem. For instance, it is expected that less computationally demanding problems, like a simple symbolic regression, will show a worse scalability, meaning that additional clients will not speed up the run very much. This is caused by the fact that these problems do not require much computational power, resulting in a relatively high overhead. However, these kind of problems do not take much computational time, and are therefore hardly worth distributing. On the other hand, realistic GP problems will require much more computational power for the evaluation of one individual. This means that such a GP problem can be distributed without introducing too much overhead.

8

W. Banzhaf et al., editor, GECCO-99: Proceedings of the Genetic and Evolutionary Computation Conference, pages 1484 – 1490, July 1999. [6] P.G.M. van der Meulen, A.M. Bazen, and S.H. Gerez. A distributed object-oriented environment for the application of genetic programming to signal processin. In Proceedings of ProRISC2000, 11th Annual Workshop on Circuits, Systems and Signal Processing, Veldhoven, The Netherlands, December 2000. [7] Adam Fraser and Thomas Weinbrenner. GPC++. http://thor.emk.e-technik. tu-darmstadt.de/˜thomasw/gp.html. [8] Helmut H¨orner. GPK. http://aif.wu-wien. ac.at/˜geyers/archive/gpk/vuegpk. html. [9] Douglas Zongker. lil-gp. http://garage. cps.msu.edu/software/lil-gp/ lilgp-index.html.

Conclusions

In this paper, a distributed environment for using GP is presented, combining a very efficient design with a high degree of flexibility. This is achieved by a carefully designed C++ implementation. The system also supports distributed processing: in a heterogeneous computer network, client processes are used for the computationally intensive fitness evaluation, while a server process takes care of the evolution process. It is shown that the detection problem is worth distributing. When adding more computers in parallel, the scaling factor drops from 100% to 75% for 7 computers due to the distribution overhead. It is expected that for more realistic GP problems, the problem can be distributed among even more computers without introducing too much overhead. More information on the GP system can be found on http://www.sens.el.utwente.nl. A demo version of the system will be available from this location in the near future.

[10] Andy Singleton and Bill Langdon. GPData. ftp: //cs.ucl.ac.uk/genetic/gp-code. [11] Sean Luke. EJC. http://www.cs.umd.edu/ projects/plus/ec/ecj/. [12] Adil Qureshi. GPSys. http://www.cs.ucl. ac.uk/staff/A.Qureshi/gpsys_doc. html. [13] Robert Baruch. JGProg. http://members. linuxstart.com/˜groovyjava/JGProg/. [14] Johan Parent. Parallel lil-gp. http://parallel. vub.ac.be/˜johan/Projects/. [15] Phyllis Chong. DGP. http://studentweb.cs. bham.ac.uk/˜fsc/DGP.html. [16] M.J. Keith and M.C. Martin. Genetic programming in C++: Implementation issues. In Advances in Genetic Programming, chapter 13. MIT Press, 1994. [17] B. Punch. How effective are multiple poplulations in genetic programming. In Genetic Programming 1998: Proceedings of the Third Annual Conference, pages 308–313, San Francisco, July 1998.

References

[18] Home page of John R. Koza. http: //www.genetic-programming.com/ johnkoza.html.

[1] John R. Koza. Genetic Programming: On the Programming of Computers by Means of Natural Selection. MIT Press, 1992.

[19] wxwindows. http://www.wxwindows.org/.

[2] John R. Koza. Genetic Programming II: Automatic Discovery of Reusable Programs. MIT Press, Cambridge Massachusetts, May 1994.

[20] M. K¨oppen and B. Nickolay. Design of image exploring agent using genetic programming. Fuzzy Sets and Systems, 103(2):303–315, April 1999.

[3] John R. Koza, David Andre, Forrest H. Bennett III, and Martin Keane. Genetic Programming III: Darwinian Invention and Problem Solving. Morgan Kaufman, April 1999. [4] A.M. Bazen and S.H. Gerez. Computational intelligence in fingerprint identification. In Proceedings of SPS2000, IEEE Benelux Signal Processing Chapter, Hilvarenbeek, The Netherlands, March 2000. [5] F.H. Bennett III, J.R. Koza, J. Shipman, and O. Stiffelman. Building a parallel computer system for $18,000 that performs a half peta-flop per day. In
