C programming notes - School of Physics

More documents

Recommendations

Info

C programming notes file:///F:/my_docs/web_phys2020/Cprogrammingnotes.html 38 of 40 19/03/2007 10:06 AM define special data types for storing these numbers. MP_INT is an integer, and MP_RAT is a rational number. However, since a multiple precision number may occupy an arbitrarily large amount of memory, it is not sufficient to allocate memory for each number at compile time. GNU MP copes with this problem by dynamically allocating more memory when necessary. To begin with you need to initialise each variable that you are going to use. When you are finished using a variable, you should free the space it uses by calling a special function. MP_INT x, y; mpz_init(&x); mpz_init(&y); /* operations on x and y */ mpz_clear(&x); mpz_clear(&y); Let's now try a full program. For example, calculating the square root of two (roottwo.c) to about 200 decimal places: #include #include int main(void) { char two[450], guess[225]; int i; MP_INT c, x, temp, diff; two[0] = '2'; for (i = 1; i < sizeof(two)-1; i++) { two[i] = '0'; } two[i] = 0; mpz_init_set_str(&c, two, 10); guess[0] = '1'; for (i = 1; i < sizeof(guess)-1; i++) { guess[i] = '0'; } guess[i] = 0; mpz_init_set_str(&x, guess, 10); mpz_init(&temp); mpz_init(&diff); do { mpz_div(&temp, &c, &x); mpz_sub(&diff, &x, &temp); mpz_abs(&diff, &diff); mpz_add(&x, &temp, &x); mpz_div_ui(&x, &x, 2U); } while (mpz_cmp_ui (&diff, 10U) > 0); } printf("the square root of two is approximately "); mpz_out_str(stdout, 10, &x); printf("\n"); return 0; To compile, link, and run the program, use gcc -o two two.c -lgmp ./two Gnuplot Gnuplot is a simple graphical plotting package. It is particuarly easy to plot graphs with it. These notes provide an introduction to its use. Numerical integration Here is an example of using numerical integration to follow the motion of a planet around the Sun: Writing fast programs
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
Page 1 and 2: C programming notes file:///F:/my_d
Page 37: C programming notes file:///F:/my_d

C programming notes - School of Physics

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?