CDP Home Assignment 1

rumblecleverΤεχνίτη Νοημοσύνη και Ρομποτική

1 Δεκ 2013 (πριν από 3 χρόνια και 10 μήνες)

87 εμφανίσεις

1 December 2013

1

CDP
Home Assignment 1

Due date:
December

8
th

TA in charge: Dmitry Zinenko


In this assignment you are required to implement a multithreaded version of a cellular
automaton called "Game of life".

The main goal of this assignment is:



To learn how to paralle
lize serial non
-
trivial algorithm



To get acquainted with Java and its multithreading primitives



To realize the impact of synchronization overhead in a multithreaded solution


Game of
L
ife

The Game of Life (or simply Life) is not a game in the conventiona
l sense. There are
no players, and no winning or losing. Once the "pieces" are placed in the starting
position, the rules determine everything that happens later.


Life is played on a grid of square cells
-
like a chess board but extending infinitely in
eve
ry direction.

A cell can be live or dead. A live cell is shown by putting a marker on
its square. A dead cell is shown by leaving the square empty.


For this exercise the game field size is not infinite but known and provided in the
input. All cells outsid
e the field are assumed as being always dead.


Each cell in the grid has a neighborhood consisting of the eight cells in every
direction including diagonals. To apply one step of the rules, we count the number of
live neighbors for each cell. What happens
next depends on this number.


1. A dead cell with exactly three live neighbors becomes a live cell (birth).

2. A live cell with two or three live neighbors stays alive (survival).

3. In all other cases, a cell dies or remains dead (overcrowding or loneline
ss).

The number of live neighbors is always based on the cells before the rule was applied.
In other words, we must first find all of the cells that change before changing any of
them.


You are encouraged to read more at

http://www.math.com/students/wonders/life/life.html

and numerous other resources on the Internet.


There are several reasons why "Game
of

Life" was chosen for this assignment. It
explicates a well known pattern of computa
tions used often in time simulations,
where the problem space is represented as a grid of cells, with each cell having a set
of parameters; the values of the parameters change at each time step depending on
those of the neighboring cells. Computations at e
ach step are usually far less trivial
than in Life, requiring significant computational effort. Examples of such applications
are various simulations in fluid dynamics, etc
.


1 December 2013

2

Parallel version


The field is partitioned into distinct subfields between diff
erent threads so that each
thread works on its own subfield. The processing is performed in parallel by all
threads. Two input parameters
hSplit

and
vSplit

define the granularity (the amount of
data processed by each thread) of parallelization as shown in
the example in Fig1.
Note that in this example the number of threads is six, so that there are two threads
which process the same row and three threads which process the same column. If the
respective dimension cannot be split into equal parts, you should
leave the remainder
to the last partition.

The
minimum granularity for each thread is a single cell
. In the example above the
maximum values of
hSplit

and
vSplit

is 6 and 4 respectively. You can assume that the
values of granularity supplied to your progr
am are correct.


The program should perform the given number of iterations (generations) and exit
(command line parameters are specified in the provided source code).



Guidelines

The highest grade will be given to those who (in the order of importance):

1.

Achieve the
maximum level of parallelism

(or maximum level of asynchrony
between the threads) available in this problem. It means that different threads
should execute independently as long as they can, and wait only when they
indeed cannot proceed furthe
r. Bad solution would require a thread to be idle
even though it can do some computations
.

2.

Use as few global data structures as possible. Global are considered objects
which are accessible by all threads ( for example, static objects)

3.

Use as few locks as
possible.

Note, that some of the requirements are contradictory, so the above order is important.
For (not necessarily meaningful)
example
, you should not use additional global data
structures if you need it for achieving very few locks. On the other hand,

you can add
more locks if they are required for higher parallelism
.

1 December 2013

3



There are also some limitations on your solution:

1.

Space used by the program should be
O(
fi
eld size
)
.

2.

A thread may not
directly change

the state of the cells which belong to other
thread
s
.
It means, that the thread which needs to change the cells which it does
not own, should
cause

the right thread to do that
.

3.

The implementation
should not use Java.until.concurrency library
. Only
basic Java synchronization primitives can be used, namely:
synchronize
,
wait,
notif
y
,
notifyAll
.

4.

You may not change the code of any provided file, except for
ParallelGameOfLife.java, but you can add any number of additional classes.

A submission that does not satisfy the above limitations will receive 0 points.


Guidance Questions

This semester we provide you with several
questions regarding key aspects

of the
parallel program. Your answers should be submitted together with the documentation
for the wet part, and they will be
part of the grade

for this assignment.

You should use those questions as
guidance

to the optimal implementation. Non
-
optimal solutions will receive considerably less points.



1)

We start with a field of 6x6 cells, with
hSplit
=
vSplit
=2, i.e. 4 different threads
handling a 3x3 area each.
Can

a thr
ead advance

some of its cells
even
when no
other threads are making progress (i.e. their cells remain at generation 0)
?
Sketch a picture of one

area, and mark for each cell the maximum generation
it can reach when no other threads are making progress.

Your

answer should
be for the general case (the best that can be said without assuming dead/alive
configuration).

2)

Your threads are performing some
computations
. What basic units

(subtasks)
can you define
? Think of the supplier/consumer model
: what are the supp
lier
and the consumers of a particular work unit
? How
do

new work units become
available? What would be the appropriate data structure to hold those work
units?

3)

What is likely to be the bottleneck in this model? Propose way(s) to reduce the
synchronization

overhead.

4)

Border cells may be read by a neighboring thread while they are being
updated, so it seems that any accesses to their status must be synchronized.
Propose a simple way to avoid it.


Technical issues

You should download the archive, which contai
ns the working serial version of the
Game of Life and all the required infrastructure for reading the files with initial
patterns. It was created in Eclipse (it is highly recommended to use Eclipse
-
you can
download it for free from
www.eclipse.org
). To use these files, you should import this
project to Eclipse (
File
-
>Import
-
>Existing Project into Workspace
-
>[select the

archive]
-
>Finish
).
Minimal compiler version for working with those files is Java 5
(aka 1.5). You
r submissions will be checked on the latest runtime (Java 6), which
should be backwards compatible.


1 December 2013

4

You should implement the method invoke in the class
ParallelGameOfLife
. It is
invoked with the parameters as provided to the program in the command line, a
nd its
results are compared with those of the serial version. If the comparison succeeds, your
parallel implementation works correctly. Otherwise your implementation is incorrect.
The data structures in the evaluation framework SHOULD NOT be considered as
a
hint for the way to implement the parallel version.


Two test fi
les of initial pattern are provided.
Y
our program will be invoked with
OTHER initial patterns
,

and thus you must test it with different inputs.
These fi
les are
in Life1.05 format, and
plent
y of other pattern fi
les can be found all over the Internet.
In particular, you can download many of them from the site:

http://www.radicaleye.com/
lifepage/patterns/contents.html


For your convenience, jar
fi
le
GameOfLife.jar

is provided,
which allows to view the
game fi
eld and its changes from generation to generation given some initial pattern. I
do not guarantee the correctness of this implementation. Furthermore,
large fi
elds ar
e
likely to be d
istorted since the size of the fi
eld is crucial.


This program can read all the pattern
fi
les in Life1.05 formats, but it ignores the initial
coordinates, so beware of consequences. To invoke it issue the command:

java
-
jar GameOfLife.jar


Grading policies

Correctness

You should submit your implementation
ONLY after it returns
"
success
"
.

We are
not looking for speedup, but for correct and technically sound implementation.
Passing
on
our test

inputs

constitutes a considerable part of your
grade for this
assignment
.

Your program will be allowed run for 10 minutes at most. If it does not complete by
then, it will

be considered as being in dead(live)lock. Similar policies will be applied
as above.

Documentation

Documentation (
both internal an
d external) is obligatory.



Internal documentation should be
reasonably

detailed to understand your
code. You are assumed to be at the stage when you have a good sense of what
should be documented and what should be not.



External documentation should desc
ribe your algorithm and the data
structures. You should analyze the quality of the algorithm, such as its space
requirements, level of parallelism, etc
.

You may consider your answers to the
guidance questions as part of the external documentation and refer
ence them
where needed.



Your code should be well structured and modular. Bad
-
written code will lead
to u
p to 10 points grade reduction.



We will also reduce up to 10 points from the grade if you do not follow Java
naming conventions, as defined in the Tutor
ial 0 slides.

Documentation

will be considered in grading.

1 December 2013

5

Performance and Optimizations

When designing the algorithms, y
ou

should

follow the guidelin
es that were given in
class. Your grade will not be affected by your program's running time, as long as it

is
less than 10 minutes. However, we encourage you to compare your running time to
other groups before submitting, to help you discover design or implementation issues.

It

i
s

OK to assume that one cell needs all its neighbors to reach the same generation
in
order to proceed
.

There will be no bonus for optimizations not directly related to the
course material.


Submission

You should submit your implementation electronically via webcourse. Submissions
above 10MB will not be accepted.
You
will be notifi
ed whe
n the submission is
received.

The submission will be allowed 2 days before the deadline and will close 5
hours after it. Electronic submission should be in the form of zip archive, which
includes


1. Text
fi
le
IDS.txt

with the names
, emails,

and IDs of th
e submitters, each on separate
line.
Submission is in pairs only.

2.
jar fi
le ex1.jar which can be invoked by
'java
-
jar ex1.jar <set of params>'
. Please
check that it works before submission. If it does not work for us, it will be considered
as failure, a
nd the

grading policies will be applied as above.

3. PDF/PS/
DOC fi
le of external documentation

4.
ZIP

archive containing all new
fi
les you created while implementing the exercise.
All old
fi
les will be overwritten.


Submit the printed version of your doc
umentat
i
on
,

source code
, and
answers to the
guidance questions

to the course box on the 1
st fl
oor.


What is a JAR file and how to create one?

http://java.sun.c
om/docs/books/tutorial/deployment/jar/build.html

http://java.sun.com/docs/books/tutorial/deployment/jar/run.html

Straightforward from Eclipse:

1) Select your p
roject

2) Export
-
> Java
-
> Jar

3) Next, Next

4) Select your main class at the bottom

5) Finish

6) Don't forget to test it!


GOOD LUCK