Michael Mohan
The project used a 2D collision detection engine created for a previous module. This application was extended to include various different C++ programming methods to generate shapes. When running the application, you can choose which optimisation techniques are used, and the program can measure how long each technique takes and output these measurements in order to experiment with the different approaches. The performance profiler can be downloaded here and the source code can be viewed here. The dissertation relating to the project and corresponding presentation slides can be downloaded below.














Performance Profiler
This project was used to investigate various methods to improve C++ performance and test these methods against each other on an example program. The tests were then used to measure the effect of the optimisation techniques and obtain quantitative data on the behaviours of these techniques. The 3 methods investigated were algorithmic complexity, methods of inheritance and data alignment, with each variation implementing different optimisation techniques. The program used to test these optimisation methods was the 2D physics engine created for the Aspects In Game Engine Development module. The game engine was retooled as a collision detection engine, used to process a number of different shapes and output the amount of collisions between each type. The collision detection portion of the program is timed for each method. The speeds can then be measured and the results compared to assess which technique is the most effective in increasing the performance of the C++ code. For each method there were a number of variations to test.
There were 3 types of algorithm used, two optimised algorithms and an unoptimised algorithm. The first optimised version used strength reduction to decrease the amount of processing needed for calculations and cut the time slightly, whereas the second reduced the amount of loops needed during calculation to provide early breaks in the algorithms. The 3 variations of inheritance that were implemented for testing were static inheritance, dynamic inheritance and no inheritance. Along with implementations of the program with data alignment activated and with no data alignment, this allowed for 18 different variations of the program that could be tested and compared. The results from the experimentation confirmed that data alignment and optimised algorithms can improve performance whereas inheritance has less of a negative effect on performance than predicted. Of the 3 optimisation types, algorithmic changes were shown to be the most effective.
When the program is run, a console window will appear and give options for how to test the program. The first option is whether or not to collect test results. If no is specified, the program will instead run a single variation of the different optimisations. The program will then prompt the user to specify which variations of the 3 optimisation techniques to use. When these are specified and the optimisation variation is run, each shape is given a random location in virtual space and the amount of collisions between each type is displayed, along with the overall amount of collisions. When the program completes processing and the amount of collisions are displayed, the time taken to calculate the collisions will be given. If the program is run and yes is specified when asked to collect test results, each of the 18 optimisation options will be run consecutively. Each variation will be run 20 times, and the times are output to a spreadsheet (CSV) file. The averages of each of the 20runs will also be output in a separate column. These outputs were used in the project to generate the results of the experimentation for analysis.
Whether the program is used to collect test results, or just to test a single variation of the optimisation techniques, the console window will give the option to specify various shape properties before executing. If the user decides to declare shape properties, the first thing that will be specified is the amount of each shape type to be processed. There are 4 shapes to specify; line, circle, square and rectangle. Once the amounts of each shape are specified, the relative sizes for each shape type will be prompted. Lastly, the width of the virtual space can be supplied to change the size of the space that the shapes are generated within. The width will also specify the height of the space. In the case that test results are being collected, these properties will be specified first, and then each of the 360 runs will use these same properties to generate the shapes and calculate the collisions (ensuring that the results are not externally affected by variations in these properties). If the user decides not to specify the shape properties, defaults will be used. 1000 of each of the 4 shape types will be generated, each of size 1, and the virtual space will have a height and width of 50. These were the properties used to run the experimentation for the project and the subsequent dissertation.