This section outlines the most relevant aspects of the implementation of the search algorithm using the SCFG representation.
In the next chapter, we propose the use of commodity GPU cards as a parallel comput- ing environment in which to run the algorithm. Utilising GPU cards in this way is called general-purpose computation on GPUs (GPGPU). The use of GPGPU places constraints on the programming language in which the algorithm is implemented, the language features used, and the memory usage by the algorithm. (We describe these constraints in detail in section 5.2.6.) The algorithm implementation used for the research in chapters 2 and 3 would not satisfy the GPGPU constraints, and so enhancing the implementation to incorporate the SCFG representation would not be practical. Instead, we create a new implementation of the algorithm that satisfies the GPGPU constraints, and can therefore run on both a CPU and a GPU.
4.4.1
GPGPU Constraints
We distinguish two categories of source code according to the environment in which it will run:
Host: Code that will only ever run on the CPU. This category includes code that parses the algorithm parameter file, initialises the representation, and writes output to the log file. Common: Code that runs on either the CPU (for the research described in this chapter) or the GPU (for the research described in chapter 5). This category contains the core parts of the search algorithm: the mutation operators, the generation of strings from the SCFG, fitness evaluation including execution of the SUT itself, the processing of the feedback data for directed mutation, and pseudo-random number generation.
Both host and common code are written in C++. However, GPGPU restricts the C++ language features that can be used by code in the common category. The most relevant of these restrictions are that memory cannot be allocated dynamically and that the C++ Stan- dard Template Library is not available (this library was utilised extensively in the existing algorithm implementation).
One of the results of the empirical investigations in chapter 3 was that the algorithm efficiency is improved if limits are placed on the numbers of bins and parents at each node in the Bayesian network. In section 4.3.5 we proposed to retain equivalent limits on the number of parent variables per child variable and the number of bin terminals per binned variable in the SCFG representation. These limits enable an upper limit to be placed on the memory used by the SCFG representation for a specific SUT. Therefore, it is possible to allocate memory statically at the start of search algorithm for the SCFG representation. The representation is then manipulated directly rather than via the Standard Template Library.
4.4.2
Assessing Valid Mutations
In the existing algorithm implementation, the entire set of possible mutations is assessed to determine which of these mutations are valid, and then one atomic mutation is chosen at random from the set of valid mutations. For example, some mutations that add an edge between nodes may be invalid because they create cycles in the network: a mutation would be chosen at random only from those that add edges without creating a cycle.
For simplicity, the implementation of the SCFG algorithm chooses a mutation from the set of possible (but not necessarily valid) mutations, and whether the chosen mutation is valid is assessed only once it has been selected. If the chosen mutation proves to be invalid, another mutation is chosen at random, up to a maximum of four attempts.
Checking the validity of all possible mutations can be time-consuming, and so by checking the validity of a single mutation after random selection is likely to improve run time. The disadvantage is that, rarely, no valid mutation may be made even after four attempts: in this case the neighbour created by mutation is no different from the current solution.
4.4.3
Representation of Binned Variables
We place a limit of 216 on the length of the interval represented by the variable and permit only integer values for both the total length of the interval and for length of bin terminals that partition the interval.
This implementation decision enables the use of the same code for both real and integer variables, reduces the memory required since lengths are represented by two bytes rather than the four bytes required by a floating point representation, avoids the need to handle floating point precision issues when generating strings from the grammar, and improves performance during string generation. If the variable represents an interval of the reals, or an interval of the integers longer than 216, the interval specified by the grammar can be scaled to meet these constraints, and then converted to the actual interval when strings sampled by the grammar are interpreted prior to executing the SUT. We additionally impose a minimum value of 1 for the length of bin terminals; if instead a minimum of value of 0 were permitted, the length could never be mutated to a larger value using the Mlen mutation operator which multiplies the current length by a constant factor.
4.4.4
Representation of Production Weights
Production weights are represented by integer values with a maximum value of 216.
As for the binned variables, this implementation decision reduces memory required by the representation compared to the alternative of storing weights as floating point values, and both simplifies and speeds up the sampling of strings from the grammar. After initialisation and mutation, weights are normalised so that the sum of weights for a variable is 256nprod where nprodis the number of productions (or bin terminals) for the variable. We additionally impose a minimum value of 1 for any weight; if instead a minimum of value of 0 were permitted, the weight could never be mutated to a larger value using the Mprb mutation operator.
4.4.5
Limits on the Length of Generated Strings
When the SCFG representation permits recursion, particular choices of production weights can lead to very long strings being generated, and in some cases the generation may not terminate at all. Therefore limits are placed both on the length of strings generated (where the length is the number of terminal symbols) and on any intermediate string (which may additionally include variable symbols) during the generation; the limits are denoted Lstring and Linter respectively. Generation of a string terminates as soon as either limit is reached. The code that interprets the generated strings in order to construct test data can choose to either discard such abnormally truncated strings or attempt to interpret them sensibly. For
the experiments described in this chapter, the latter choice is made. Both of these limits are parameters to the algorithm.
4.4.6
Pseudo-Random Number Generation
In order to ensure a fair comparison between algorithm implementations running on the CPU and GPU, we require a common pseudo-random number generator (PRNG). The GNU Scien- tific Library was used to generate pseudo-random numbers in the existing algorithm imple- mentation. However, this library is incompatible with the GPGPU constraints. Although our chosen implementation of GPGPU, NVIDIA’s CUDA framework, provides a PRNG which can be called in both CPU and GPU code, preliminary experiments showed that the gener- ator was very slow when called from the CPU compared to the GPU performance. Instead, a bespoke 64-bit implementation of Marsaglia’s XORShift algorithm (Marsaglia, 2003) was used as the PRNG on both the CPU and GPU.