7: Optimize the Game of Life

Clone the following repo with code that simulates the two-dimensional (original) version of Conway's game of life:

$ git clone /home/l/lcl_uotphy1610/lcl_uotphy1610s1466/gameoflife

You will get to profile this code, analyse the bottlenecks, and then try to improve the performance of those bottlenecks.

We often need to rebuild the code with different compiler flags depending on whether we want to debug, profile with gprof, profile with Linaro MAP, or produce an optimize executable.  The Makefile supports such different "build"s  by using a variable 'BUILD'.  I.e., `make BUILD=debug` produces a debuggable executable called "gameoflife.debug", while `make BUILD=release` produces an optimized executable called "gameoflife.release".  The Makefile will also produce a link to the latest built executable called just "gameoflife".

The code also comes with unit tests which you can run with `make BUILD=release test`.

Step 1: Initial timing

In a debugjob on the teach cluster, build, then run the release version of code as follows:

$ time ./gameoflife 1000 1000 1000 0.183 output.txt

The first and second parameters are the dimensions of the grid, the third parameter is the number of time steps, and the fourth is the initial fraction of alive cells. The final argument is the output file.

Record this first timing in a file called 'timings-report.txt'; make sure to add some text to explain what you did as you will append to this file later on.

Step 2: Profile with gprof

The first task is to profile this code with gprof.  For that, create a new BUILD=gprof case in the Makefile that sets the appropriate flags for gprof. Despite the recommendation in class, for the optimization level, use `-O3`.

Then compile the code for that build, and run the same case as in Step 1.

This should produce the file gmon.out. Now execute 'gprof gameof1d gmon.out', and capture the full output of it in a file 'gprof.functions.out'. Include this file in your git repo.

From the top of this file, you will be able to identify which two functions are the most important ones, i.e., the two bottlenecks.

One will have to do with the output, and one with the time evolution.

Also run gprof as `gprof --line gameof1d gmon.out` to try and see which lines in the code are the most important ones, and include that output as a file 'gprof.lines.out'.

Step 3: Profile with MAP

The expensive lines are a bit hard to find with gprof (in part because of the high optimization level). Luckily, on the Teach cluster, we have a better and more accurate tool, Linaro MAP. The `map` command is available when the module `ddt-cpu` is loaded.

You will need to create a new BUILD=map case in the Makefile with the appropriate flags (still using `-O3` for consistency with the previous case). Build this build, and run the same case through MAP. Take two screenshots showing the most important lines in the two bottlenecks, and include them in your submission (ideally in the repo, but as separate files is acceptable as well).

Note: if for some reason MAP's window won't open for you, run map with the `--profile` flag, which does not open a window but instead generates a "Profile Data File" called `gameoflife_1p_1n_DATESTAMP.map`. Copy this file, along with your source code, over to your computer.  Then download and install version 23.1 of MAP from https://www.linaroforge.com/download-forge-old-version , with which you can open the "Profile Data File". You do not need a license to view the file.

Task 4: Improve the code's performance.

Try and understand what might work faster for the two bottlenecks (i.e., one in the time evolution and one in the output). Make sure to keep your changes under version control, and keep running 'make BUILD=release test' to ensure you did not break anything. The format of the output should not change.

Attack the bottlenecks one at a time, and append the timings of:

$ time ./gameoflife 1000 1000 1000 0.183 output.txt

(always the release version) in the file 'timings-report.txt' with a short description of what you changed in the code.  It is a good idea to keep using MAP to check that the bottlenecks decrease in importance.

We continue to expect you to use best practices like commenting code and having several meaningful git commit messages. Submit your git repo for the code, supplemented with the output of gprof, the report file and the map screen shots by midnight March 20th, 2026.