CS87 Lab 1:

Have timing code in your solution around the GOL main computation (don’t include grid initialization or outputting the result to a file). Use gettimeofday.

Calls your program makes to usleep and system("clear") to implement animation of the game board should only be made when the program is run in board printing mode; runs with the -x command line option should not trigger any calls to usleep).

Use perror to report errors from system calls.

Detect and handle all errors. Your program can call exit(1) if the error is unrecoverable (after printing out an error message of course) This means that any time you call a function that returns a value, there should be a check for error return values and they should be handled: do not just assume that every function call and every system call is always successful.

Your solution should be correct, robust, and free of valgrind errors

Your code should be well-commented code and use good modular design. See my C documentation for C references and a C code style guide.

The grid sizes. Try different powers of two (64, 128, 256, 512, 1024, 2048, …​) You do not have to try every power of two between your min and max sizes, but run a several intermediate sizes between your smallest-sized and largest-sized boards.

The number of threads. Again, increase by powers of two: (1, 2, 4, 8, 16, 32, …​), and/or multiples of the number of cores on the machine you are running, and again you do not need to include every power of two between your min and max.

Compare row-wise vs. column-wise board partitioning.

The number of iterations (try a couple different values that show differences across runs). In general you should you should run each gol experiment for many iterations so that there are multiple synchronization points in a run and as a result you can see some synchronization effects on scalability.

who to see who else is on a machine you are running on, and try another machine if you are not alone.

top -H or htop to see the system load on the machine. The -H lists individual threads running on the machine (you can see your 4, 8, 16, etc running). htop provides a nice gui interface to these data.

Memory usage: make sure that the grid sizes are not too large to fit in RAM. I don’t think this really will be a problem, but double check your a run with your largest sizes before running experiments to see if the system is swapping. htop will show if the swap partition is being used, you can also look at some information in /proc. As your programs run, in another window run:

watch -n 1 cat /proc/swaps
Filename                                Type            Size    Used    Priority
/dev/sda2                               partition       2072344 0       -1

Using screen or tmux for running long-running experiments is useful. Also making use of script and writing and using bash shell scripts to run experiments is very helpful. See Resources for Experiments and Writing for more details on using these.

cron is useful for submitting jobs on a specific machine at a particular time (for example, you could use cron to run your experiement run script at 3am). See Handy Resources for more information about cron.

some useful tools vim, ssh, scp, tmux, finding idle machines, latex, git, …​

my help pages

CS department help pages

The CS31 pthreads GOL lab and the CS31 sequential GOL lab assignment have hints and resource for implementing the GOL and pthreads GOL programs. Note who is responsible for allocating and freeing memory space passed to (and returned by) these routines, and note return values and check for and handle error return values.

The man pages for C library, system calls, and pthread functions are very helpful.

getopt command line parsing.

cp -r ~newhall/public/getopts_example/* .

Chapter 2 of Dive into Systems covers C programming, structs, pointers, pass-by-pointer parameters, switch statment, dynamic memory allocation, etc. And some other C programming references.

rand and srand C library random number generator and seeding function (pass srand time(NULL) to seed with current time).

valgrind and gdb guides. Also see Chapter 3. Also, guide for using gdb to debug pthread programs.

atoi converts a string to an integer. For example, int x = atoi("1234"), assigns x the int value 1234. See the man page for more info and similar functions: (man 3 atoi)

use perror to print out error messages from failed system calls:

FILE *in;
in = fopen(input_file, "r");
if(in == NULL) {
  perror("fopen failed. Exiting\n");
  exit(1);
}

gettimeofday to add timing code around jut the GOL game playing part of your code (you should already have this in your CS31 starting point, see the CS31 GOL assignment page for more details if not)

File I/O in C (you should not need to modify the file I/O part from your CS31 solution).

make and writing Makefiles

See the Running Experiments section for information about choosing machines and running on chervil.

Here are some useful tools vim, ssh, scp, tmux, finding idle machines, latex, git, …​

See my Tools for examining system and runtime state for some tools you can use to determine the

My Tools for running experiments and collecting performance measurements screen or tmux, script, cron, and bash scripts may be particularly useful. To avoid losing test results, I suggest either redirecting test output to a file, or running experiments in script, which will save all terminal output in a file (the default name is typescript). Just run script outfile, start your experiments on the command line, and then run exit to exit out of script. All the terminal output will be saved in a file named outfile. You can clean up the output file a bit by running dos2unix on it:

$ script results
Script started, file is results
% ./run
  ...
% exit
Script done, file is results
$ dos2unix -f results
$ dos2unix -f results

time ./a.out show the total runtime, and user and system times associated with executing a.out.

shell scripts: You can write and use shell scripts for running a set of experiments. With your repo is one example of a bash script for running a set of experiments that you can use as a starting point for different run scripts to run sets of your experiments. Here is another example

ls -l                   # lists file permissions (rwx)  x: execute is set
chomd 700 testrun.sh    # sets rwx permission for file owner if needed
./testrun.sh            # then you can run the script
./testrun.sh  > resultfile

./testrun.sh  > resultfile

tmux or screen are useful for running a long set of experiments: you can run scripts from within a screen session late at night, wake up the next morning re-attach to the screen session and see the results.

latex info and latex links. latex is Unix’s document writing software. You do not have to use latex for writing your report, but it has very good support for some things that are common in scientific writing such as representing mathematical expressions, so you may want to give it a try. I have some example latex documents that you can grab to use as a starting point in ~newhall/public/latex_examples/.