The results to be obtained from the simulation could be divided into two main categories: those representing data on aspects of the performance of the multiprocessor architecture, and data on the behaviour of the rewrite interpreter. It is important to note at this stage that the data on the interpreter was in the form of "real1’ timings, whereas that on the machine performance was produced by calculations based on the proposed design of the hardware.
8.3.2. Rewrite Interpreter Timings
Data was needed on the number of processes produced during a given query and the time taken for each process to execute. It was also essential to measure the time taken by the different subtasks in process evaluation in order to check that process spawning was not introducing unacceptable overheads. Thus for each process measurements were made for total evaluation time and the following subdivisions of evaluation time:
a) set-up time, the time taken by the interpreter to convert an existing process structure into an expression tree,
b) rewrite time, the time taken to rewrite an expression tree until no further alterations possible, or until an OR node encountered,
c) spawn time, the time measured between first recognition of an OR node and the production of a full set of new process structures ready to be allocated.
8.3.3. Machine Performance Data
Results on machine performance were sought for a range of different machine configurations. The first result to be obtained was a measurement of the total time taken to complete each query. This allowed speedups to be calculated and gave an indication of the effect that contention for the communication medium was having on overall performance.
However in order to understand what was happening in the machine during query evaluation it was necessary to obtain results on the execution and starting times of each process. When these were related to the processing element to which a process was allocated the pattern of machine usage can be determined. With a good scheduling system it was expected that the number of processing elements in use would rapidly increase to the maximum number and that this level would be maintained throughout query evaluation.
Incoming data packets were written into the input memories of a processing element, each input memory serving a particular bus. As discussed in Chapter 6.5.4, the method of allocation of processes to processing elements was by assessment of work load, and bus allocation was performed on a round robin basis. The intuitive belief was that this method of bus allocation should result in a reasonably balanced usage of input memories for each processing element. In order to confirm this, measurements of the size of data packets waiting for execution in each input memory throughout process evaluation were required. The simulation does not manipulate data packets as such, maintaining the original format of the abstract process structure. This has meant that additional functions to relate the calculated data packet size with the input memory have been written and this information updated throughout query evaluation. The final result was a table of maximum input memory usage for each processing element and the time at which the maximum was first reached.
The information required on the transmission of data packets across the communications medium fell into two categories: the bus usage, including any transmission delays because of non availability of a bus, and the size and transmission time for individual data packets.
The question of return of results, ie the correct binding values, to the controller was discussed briefly in Chapter 6.5.7. This could be achieved by use of a common bus shared by all processing elements, or more localised busses used by fewer processing elements. In order to assess which design should be chosen it was important to have data on the pattern of results return. If positive results become available in such a manner as to introduce little contention for a globally shared bus there is no point in constructing a more complicated system. With this in view information was sought on the times at which final bindings were produced by processes, and the size of data packets that these bindings give rise to. The format proposed at present for the results data packet is identical to that of the spawned process data packet, as it is recognised that "results" may not always consist solely of binding values, but in the case of "uncomputable" expressions will include reference to the expressions themselves. More work in this area is indicated but it was hoped that the simulation would provide data on which to base future design decisions.
8.3.4. Results Summary
To summarise, the requirements for results involved timing measurements for each query evaluation run. For each combination of system definition, ie processing element/bus configuration and process scheduling algorithm, records were made for:
a) process start and finish times,
b) within each process, the set-up, rewrite and spawn times, c) process/processing element allocation,
d) input memory usage levels,
e) data packet sizes and transmission times, f) bus usage and delays in obtaining busses, g) results times and results packets sizes.
These results were written to file during query evaluation, and the data analysed in various ways afterwards. This represents a fourth aspect to the software developed during the project: functions were included in the simulation to calculate and output the appropriate data, and a separate data analysis program was written to show the results in a tabular or graphical
The intention was that this series of tests and subsequent data analysis would complete the work on the simulation. However as will be shown the results obtained from the first series of tests produced somewhat unexpected results, and led to the decision to alter the testing strategy and include further modifications to the system.