Please install these libraries / environments, AWS node is not necessary.
This repository features two versions of Conway's Game of Life, collaboratively implemented by Gordon Wai Hin Kam and Ivan (Ka Ho Leung) in Go.
Conway's Game of Life is a cellular automaton devised by the British mathematician John Horton Conway in 1970.
A user can only interact with Game of Life by creating an initial configuration and observing its evolution.
Conway's Game of Life is implemented in a closed domain by reading an nxn.pgm file, which sets up the initial state based on the provided image grid.
At each cell in matrix update in time the following transitions may occur to create the next evolution of the domain:
- any live cell with fewer than two live neighbours dies
- any live cell with two or three live neighbours is unaffected
- any live cell with more than three live neighbours dies
- any dead cell with exactly three live neighbours becomes alive
Parallel Implementation: This version utilizes multithreading to enhance performance by distributing the workload across multiple CPU cores via Channels and Mutex Lock to achieve free Race Condition.
Parallel-Distributed Implementation: This version extends the scalability by distributing the processing across multiple nodes via RPC (Remote Procedure Call) in a network and as well as each node distributing the workload across multiple threads.
When you run the game, you can press the following keys during the execution of Game of life:
-
Press
swill save the state of world and output thenxnxt.pgmfile in the image (depends on which version you are running) directory, wheretis the number of turns when you presss. -
Press
qwill terminate the game and output thenxnxt.pgmfile, similar as above. -
Press
pwill pause the state of world, and presspagain will resume the game. Note, you can presssandqwhen the game state is paused. -
(Only works for Parallel-Distributed System) Press
kwill gracefully shutdown all the components in distributed system.
When you run the game, the CLI will output the current number of alive cells and turns for every 2 seconds.
Go to parallel directory.
If you want to run the Parallel version of game of life, run the following command on terminal:
go run .
If you want to run the test of game of life, run the following command on terminal:
go test -v -race
-v is a flag which tells the Go testing framework to print more detailed output about the tests that are being run.
-race is a flag which detects any race condition.
Go to parallel_distributed directory.
This is getting tricky compared to parallel version.
You can run it either on AWS nodes or locally.
First, we need to run the broker.
You can add -port flag or not. If you add port flag then replace <port> with the port that broker want to listen on
Run the following command in terminal:
go run broker/broker.go -port="<port>"
port flag is the port that broker listen on. If not specified, the default port number is 8030.
Second, we need to run the server.
You can add -broker flag or not. If you add port flag then replace <broker-port> with the port that broker listened on. Similar to port flag.
Run the following command in terminal:
go run server/server.go -broker="<broker-port>" -port="<port>"
broker flag is the port address that broker listen on, please enter the correct broker address as you enter above. If not specified, the default port number is 8030.
port flag is the port that server listen on. If not specified, the default port number is 8050.
Note: you can run more than one server by changing the port flag number.
Lastly, if you want to run the game locally then run the following command on terminal:
go run .
if you want to run the test then run the following command on terminal:
go test -v -race
Note: It is normal that the SDL window shows a black screen for Parallel Distributed System since we have not implement the events to sdl window.
This section provides details on the benchmark tests conducted to evaluate the performance and efficiency of implementations.
The primary objectives of our benchmark tests include:
- Performance Evaluation: Measure the execution time and processing speed under various computational loads.
- Scalability Assessment: Determine how effectively the software can scale up with increasing input size.
- Resource Utilization: Analyze CPU and memory usage during peak operation conditions.
In the benchmark_test directory, benchmark_test.go and halo.go are benchmark test. You can simply copy these files to the version of Game of Life (gol).
benchmark_test.go is used to test the performance of parallel component.
halo.go is used to test the performance of direct halo exchange between servers.
Copy the Benchmark function you want to test in the version of Game of Life.
cp benchmark_test/<Benchmark.go> <version_of_gol_directory>
Then, run the following command:
This will repeat each sub-benchmark 5 times, but each result will be reported individually.
go test -run ^$ -bench . -benchtime 1x -count 5 | tee results.out
We can now use our benchstat library to convert raw benchmark output to a 'Comma Separated Values' (CSV) file.
go run golang.org/x/perf/cmd/benchstat -format csv results.out | tee results.csv
There are some python script to plot the graph of performance.
Similarly, copy the python plot program you want to test in the version of Game of Life.
cp benchmark_test/<Benchmark.py> <version_of_gol_directory>
Run the following command:
python <Benchmark.py>
We can test the program easily by running the following command:
./benchmark.sh <no_of_servers> <no_of_threads>
(the broker need to be started before running benchmark.sh)
<no_of_servers> refers to the number of workers that will work in the whole distributed system and
<no_of_threads> refers to the number of threads that will be used to process the game in each individual worker in parallel.
With this shell script, we can easily customize the number of servers/threads and the port of the first server that we want to test.
After triggering the shell script, it will automatically start all the workers with some timeout, and finally starting the client to call the broker to start the whole process.
After everything finished processing, the shell script will cleanup all running process (workers and client) that isn't quit properly.
We have written a report to analyse the performance in each component and also the functionality of Game of Life we have implemented in Report.
© 2024 Gordon Wai Hin Kam & Ivan Leung Ka Ho. All rights reserved.