Implementing the Game of Life with Pthreads (due Sat Oct. 4)
The Game of Life has garnered much attention since its development in 1970 by John Conway (see its entry in Wikipedia). In this assignment you will be developing a parallel version of the class game of life and running it on the Natural Sciences Computer Cluster (NSCC).
Logging onto NSCC
You all have accounts on the Natural Sciences Compute Cluster (NSCC) in order to run code for CS 336. The node we will be directed to has 8 processors, with each pair of processors sharing a 6MB L2 cache. There is no queueing software installed, so it is up to you to be careful not to hog the machine nor to clobber other people's jobs.
My advice is to develop and test your code on your machine first. You can even use 8 threads to simulate the use of 8 processors - there just won't be a speedup. Once you are reasonably happy with your code, use an SFTP or SCP server (I use SFTP on Fugu) to move it (and its makefile) to the network server (colby0.colby.edu). That puts the code into a directory that NSCC can access.
To run your code on NSCC, you must log onto it using SSH. In a Terminal window, type
ssh nscc.colby.edu. The system is set up to automatically place you in your home directory associated with the colby0 file server. Tho see who else is logged in to the machine, type
who on the command line. To see who is running jobs on the machine, type
top (then, to quit it, type
q). If none of your classmates are actively using it, then it should list
FahCore_a2.exe as the process taking up most of the CPU time for each processor. This is code Randy is running in the background. It has a low priority and will yield to any processes you start.
If you have any problems using this computer, let me know AS SOON AS POSSIBLE!
What to Do
gol.c, which has in it the sequential code to play the game. There is also
Makefile. Do a sanity check - compile and run it on NSCC. It should print out:
Running the parallel version
It took 0.000000 seconds to run the parallel algorithm with 1 threads
Running the sequential version
It took 0.000000 seconds to run the sequential algorithm
ERROR -- The boards differ!
Let me know if there is a problem.
- Familiarize yourself with the sequential version of the code. In particular, note
- This code is designed to run the game of life with an initial board configuration that is tiled with toads (the 2-phase oscillator we saw in class).
- There are several macros that act as the "tuning knobs" for the code. The two that control the problem size are
PRINTINGmacro determines whether or not the current board is printed to the screen after every generation. For small problems, set it to 1 to see the evolution of the cells. Otherwise, set it to 0.
- There are several helper routines. Read their header comments to determine what their role is. The code is heavily commented, so I will not repeat the information here.
- Add support for a parallel version of the Game of Life by augmenting the code in
gol.cto use Pthreads.
- There is a function named
parallel_lifethat you will need to fill in. This is the function that should call the Pthread create and join routines. Model it after the
mainfunctions from previous homeworks.
- You will need to write the main thread function. Model it after the
sequential_lifefunction in this homework, but each thread should be responsible for simulating the lives of a subset of the cells. The data decomposition you use is up to you -- by rows, by columns, or by blocks.
- Note that after each generation, each thread should wait at a barrier. Once all threads have reached the barrier, it will allow them through. This ensures that all processors are working on the same generation at the same time. The code for the barrier function is already included in
- There is a function named
- The main function is designed to call the parallel algorithm, hold on to a pointer to the final board configuration, call the sequential algorithm, hold on to its final board configuration, and then compare the final configurations. It reports an error if the boards are not the same (a built-in tester for your code!).
- You will want to test your code for different numbers of threads and for different problem sizes.
What to Turn InTurn in your code and a short report by emailing me. Put "CS336" in your subject line so that my mail filters will catch it and I will notice it right away.
- Code should be well commented. If you turn in non-working but well-commented code, I will be able to help you figure out what your problem is and your grade will suffer less both in the short term and the long term (because you will be better able to learn from your mistakes). It is better to think through a problem and share with me your process than to give up and turn in something that doesn't reflect the amount of time and effort you have put into the homework.
- The main comment associated with any functions you add (e.g. the main thread function) should have in it a short statement about what the function does, what parameters it takes, what it returns, and which global variables it accesses and changes.
- Start coding early so that you can ask me if you have any problems. I don't want you to get stuck on the code and be unable to do the speed-up analysis!
- Bruce has written helpful tutorials on the Terminal and Makefiles. Check them out.
- Be careful if you mount a network directory on your Mac. If you use your Mac Terminal in a mounted directory then you are still "on" your Mac. Specifically, if you compile code, the binaries will execute on your Mac. If you want to create executables for a different machine (.e.g. one of the dwarves or a node on the cluster), then you must log into that machine using
sshand then navigate the appropriate directory.
- Separating code from executables makes it simpler to compile and run code on multiple machines. Everything in the
srcdirectory is portable from machine to machine, but the executables in the
bindirectory are specific to that machine. For machines on the network that share a file system but not an architecture, this may mean you must keep track of which machine you last compiled on. If your code doesn't run, then recompile it.