Console Development – Week 1,2,3 Semester 2

February 13, 2009

Filed under Console Development
Tags: Computer, Console Development, Games, Programming

leave a response

Reminder

Console Development is a module that is running though both semesters this year. As a reminder, Console Development is a module in which we will be developing a program to run on a PSP, the main focus of the module is to increase our knowledge of developing with system limitations in mind and Optimisation will play a large part of the module.

In the previous semester as part of the module I had to learn about MIPS Assembly Language and write a few different programs using this Assembly Language. Learning this was a great help and increase my level of knowledge about computer architecture and how our code we write in higher level languages gets translated into assembly code and eventually into machine code. Also as part of last semester I learnt a lot about the inner workings of computers and mainly about how the Cache and memory can be a critical part of optimisation.

Week 1

At the start of this semester we had to take a sample of Sonys which runs on the PSP and improve its memory organisation in groups of 3 to 4. The main optimisations that we were to focus on were Preloading cache lines, changing the layout of structs and helping the compiler overcome aliasing issues. We picked a sample which was called Moonball, it was a game in which you had to shoot balls before the moon reach one end of the screen. At first glance this program was quite efficient and looked as though not a lot could be done to change this.

After searching through the source code for a while we came across a struct which look a little peculiar, the struct its self had a flag in it which was used to see if a Particle needed to be drawn, if the flag inside the struct was set to true then it would draw the particle, if false the it would bypass that particle and would not draw it. The flag and the data which needed to be accessed was all in the same struct, we came up with an idea which involved taking the Data out of the struct and putting it into another struct on its own, then each instance of the old struct has a pointer to another instance of the new struct. The reason behind doing this was to improve the number of structs which could fit onto one cache line, and hopefully improving and reducing the cache miss rate. We had to use some basic profiling tools to figure out if this changed worked and according to the Sonys kernel profiling code we reduced the Cache miss rate from 280 down to 220 misses per frame!

We had to present our findings to the rest of the class in the form of a powerpoint presentation.

Week 2 and 3

This week and the previous week we have been given a tool called Tuner which helps us with profiling, this tool can tell us a lot more information that we could find out ourselves and it gives it us a lot faster! Using this tool we had to use the same sample as before and give proof that it has improved the performance of the application.

Using Tuner we profiled the original sample and our changed version only to find out that the time it take to run each of the versions was the same, we may have improved the cache misses but the time it took to render each frame was still the same as before, so all our hard work from the previous week was undone.

We have been profiling the code ever since trying to improve some other parts of the code but the sample so far looks very clean and is hard to change! We have to present our findings this week to the class once again.