Prof. Dr. rer. nat. Roland Wism ¨uller
Exercise Sheet 3
(Deadline: 21.01.2022)
Parallel Processing Winter Term 2021/22
Preparation:Download the program codes for this exercise sheet from the Internet:
https://www.bs.informatik.uni-siegen.de/web/wismueller/vl/pv/u3Files.zip
Exercise 1 (Compulsory Exercise for 5 CP and 6 CP): Parallelization of a solver for the Sokoban game
In the downloaded ZIP file, you will find the code of a sequential (brute-force) solver for the game Sokoban (“warehouse manager”). In this game, a player has to push objects (often boxes) to predetermined target positions (storage locations). The boxes can only be pushed, but not pulled, and only one box can be pushed at a time.
Background information on the game can be found on Wikipedia:
• http://en.wikipedia.org/wiki/Sokoban(English)
• http://de.wikipedia.org/wiki/Sokoban(German) The code is structured into the following classes:
• Playfield(inplayfield.handplayfield.cpp):
This class represents a given level of Sokoban, i.e., the playing field (board) with the initial positions of the boxes and the player as well as the positions of the targets.
Internally, the playing field is not represented as a two-dimensional array, but in the form of numbered fields.
In addition, the left, upper, right, and lower neighbor fields are stored in an array for each field (if any, i.e., only if the field is not a wall).
This class also contains the code for printing the playing field, where the output is colored for the sake of cla- rity. If this makes problems, the statement#define COLORcan be commented out inplayfield.cpp.
• Config(inconfig.handconfig.cpp):
This class represents a configuration in the Sokoban game. This includes the playing field (shape, number of fields, positions of the targets, ...), the positions of the boxes and the position of the player. Each configuration may also be represented by a configuration number (i.e., an integer). This is determined by a configuration number for the box positions and the position of the player. By encoding the configuration as a “small”
integer, a bit set can be used during the search to store the set of all configurations already visited.
• Converter(inconverter.handconverter.cpp):
This class (with only static attributes and methods) converts a configuration of boxes, i.e., an array containing the positions of the boxes, into an integer (the configuration number), and vice versa.
• BFSQueue(inbfsqueue.hundbfsqueue.cpp):
This class is used to support breadth first searches. It essentially implements a queue for configurations connected to a set (implemented as a bit set) that stores the already examined configurations.
The most important method islookup and add(). It checks whether a given configuration is already contained in the bit set. If not, the configuration is entered into the bit set and the configuration, the index of the previous configuration, and the number of the moved box are added to the queue.
• DFSStack(indfsstack.hunddfsstack.cpp):
This class implements a stack of configurations for depth first search. It keeps track of the path from the initial configuration to the currently examined configuration.
• DFSDepthMap(indfsdepthmap.hunddfsdepthmap.cpp):
For depth first search, this class performs a mapping from a configuration number to the lowest depth found so far for the corresponding configuration (i.e., the minimum number of moves from the initial configuration to the given configuration, which has been found until now).
The most important method islookup and set(). It checks to see if there is an entry for the given configuration number with a depth less than or equal to the given (new) depth. If so,falseis returned. If
1
not, the depth of the configuration in the map is set to the new depth, andtrueis returned.
The main program insokoban.cppcontains two fundamental routines:
• doBreadthFirstSearch()executes a breadth first search in order to find the solution,
• recDepthFirstSearch()executes a depth first search.
The structure of these routines as well as their working principles are explained in section 5.3 of the lecture slides.
a) Parallelization of breadth first search:Parallelize the functiondoBreadthFirstSearch(). Note that all configurations of the depthdepth-1can be examined in parallel. Remember to realize mutual exclusion where necessary.
Note that when parallelizing the code in the suggested way, the order in which the successor configurations are entered into the queue changes, so strictly speaking, data dependencies are violated. In this exercise, this is allowed for you as an exception. However, it is important that the number of examined configurations for each tree depth exactly matches that of the sequential program. For better control, this output is an sent to standard error, so that it can be separated into a file with./sokoban level.txt 2> output.txt.
The enclosedmakefileallows you to check the correctness of this output by callingmake test.
In the directoryLEVELSyou will find some Sokoban levels as well as the associated outputs for testing. In themakefile, you can select the level file to use. Note the complexity of each level, as specified in the file LEVELS/README.txt.
b) Optimization of breadth first search:Measure the speedup achieved, perform a performance analysis (you may use Scalasca, if possible) and try to optimize your code. In particular, you can try to create a lock- free implementation of the methodBFSQueue::lookup and add(). Because OpenMP does not (yet) support the corresponding atomic operations, use the built-in gcc functions:
• bool __sync_bool_compare_and_swap(type *ptr, type oldval, type newval)
• type __sync_fetch_and_or(type *ptr, type value)
• type __sync_fetch_and_add (type *ptr, type value) Here,typecan be an arbitrary integer type or a pointer type.
Seehttp://gcc.gnu.org/onlinedocs/gcc-4.4.5/gcc/Atomic-Builtins.htmlfor mo- re details.
The gcc compiler also supports newer builtin fuctions that support the C++-11 memory model. These functi- ons are more flexible, but also a bit more complex to use. You can find a documentation of these functions at https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html. If you li- ke, you can use the functions__atomic_compare_exchange_n(),__atomic_fetch_or(), and __atomic_fetch_and()instead of the functions shown above.
c) Parallelization of depth first search:Parallelize therecDepthFirstSearch()function using OpenMP tasks. To do so, do not directly execute the recursive calls at a certain depth in the tree, but instead create OpenMP tasks. Think carefully which arguments of the call must be copied (firstprivate) and which must beshared. Also consider where mutual exclusion is required.
Test your program by callingmake DEPTH=depth test, wheredepthis the maximum depth at which the tree should be examined. It is best to use the values specified inLEVELS/README.txt.
Note: If neccessary, a copy of the stack (argumentDFSStack *stack) can be created using the copy constructor:
DFSStack *newStack = new DFSStack(*stack);
Do not forget to deallocate the copy again, usingdelete.
d) Optimization of depth first search:Measure the achieved speedup (to think about: why is the speedup not meaningful here?), perform a performance analysis (you may use Scalasca, if possible) and try to optimize your code. In particular, try to implement the methodDFSDepthMap::lookup and set()lock-free.
2
