C programming notes - School of Physics

C programming notes
file:///F:/my_docs/web_phys2020/Cprogrammingnotes.html
39 of 40 19/03/2007 10:06 AM
Reasons for worrying about how fast a program is include:
if it is interactive, and reponsiveness is important,
if it is pushing the boundaries of practicality (e.g., it might takes weeks to run).
Hints on improving speed:
use a clever algorithm.
identify the time-critical parts of the program, and concentrate on improving those.
examine memory use as well (e.g., try to reduce the amount of memory being used, and keep the usage localised
as opposed to jumping around randomly).
iterate most rapidly over the rightmost subscript in arrays, since this will lead to better localisation of memory
use (and hence greater likelyhood of cache hits).
use optimisation (e.g., -O1, -O2, or -O3; see "man gcc" for details).
try optimising for small program size (-Os).
in general, try not to be "too clever" - the C compiler can quite often do a better job if your program is clear.
make the critical parts of the program as small (in terms of bytes of instructions) as possible - they will then be
more likely to fit in the CPU's "instruction cache", resulting in better performance.
declare often-called functions as "inline", which eliminates the expense of the function call and copying the
arguments to/from the stack. This technique should be used with caution, since it makes the program larger, in
which case it may no longer fit in the instruction cache.
avoid printing out lots of unnecessary information. Formatting and writing text to the screen is quite CPU
intensive.
2D cellular automata - Conway's Game of Life
In 1970, the mathematician John Horton Conway published the description of a simple 2D cellular automata which he
called the Game of Life. Cells in a 2D grid were either "alive" or "dead", and their state in the next generation was
determined by their current state and the number of nearest neighbours (from 0 to 8, inclusive). The rules were chosen
to simulate some properties of biological systems (e.g., a cell would die of "overcrowding" if too many of its
neighbours were alive, and die of "lack of support" if too few of its neighbours were alive).
Here is a "simple" example of how to program the Game of Life on a computer.
If we are interested in following the evolution of the game for many thousands of generations, it is advantageous to
think of ways of speeding up our simple implementation. The first thing to try is to turn on full optimisation during the
compilation, using the "-O4" switch. The next step is to make the critical functions "inline" (see here for the code). We
can also think about the algorithm, and realise that a lot of our calculation of the number of nearest neighbours was
involved in handling the special case of being on the boundary; we can re-write our program to separate out the
boundary case, thereby allowing a simplified (faster) function to do most of the neighbour calculations, at the expense
of increased complexity in handling the evolution from one generation to the next. Finally, we can try to use the fact
that much of the Life "universe" tends to be sparsely populated, allowing us to produce a second
neighbourhood-calculating function for the special case that the preceeding cell had no nearest neighbours. These are
by no means the only speed-ups that are possible, but they give you some flavour of what is possible.
The following table gives the time taken to follow one million generations using a 850MHz Pentium III computer and
the various tricks from the last paragraph.
Time Technique
[seconds]
--------------------------------------------------
330 Original program, no optimisation
205 Original program, -O4 optimisation
113 Inline function calls
45 Boundary case handled separately
37 Sparse population handled separately
So, we have managed almost a factor of ten improvement in speed over our original attempt.
To show why this might be useful, let's now alter our program to automatically identify glider patterns (those that can
self-propagate). We will choose a brute-force technique where we randomly seed the centre of our rectangular
"universe" with alive/dead cells, and then evolve the system until one of the boundary cells is hit. When this happens
we stop the evolution and print a 21x21 grid around the cell, hopefully capturing a glider in full flight! Here is the code,
and you can see that it is a straightforward variation on the earlier program. It typically finds a glider within 2 seconds