Discussion

In this section, we first discuss some past job-level-like research work, and then some issues about job-level computation in the implementations.

4.4.1 Past Job-level-like Work

The research into solving Checkers [46] was separated into two parts: the proof-tree manager and the proof solvers. The proof-tree manager, like the client in our model, used the PNS to identify a prioritized list of positions to be examined by the proof solvers, like jobs in our model. Their manager generated several hundred positions at a time to keep workers busy, and they did not consider pre-update.

The research [11] proposed a meta MCTS to build opening s in the book of Go. In their method, a tree policy was used to select a node in the UCT tree, while an MCTS program

0

was used to generate moves in the simulation. The program maintaining the UCT tree acts as the client, while the MCTS program used in the simulation acts as the job.

We believe that the job-level computation model can also be easily applied to many other search techniques. In addition to JL-PNS, our ongoing projects are seeking to apply the job-level model to other game search applications [60], such as job-level Monte-Carlo Tree Search (JL-MCTS) for Go, job-level alpha-beta search (JL-ABS) for Chinese chess opening, and job-level learning (JL-Learning) for tuning the weights or scores in games such as Connect6 and Chinese chess.

Another example is solving triangular nim, which can also be applied on job-level computation model. The 8 layer and 9 layer triangular nim are both solved [49][50]. As solving 8 layer triangular nim an example, all the positions are categories into 16 blocks, and we need to solve all the blocks. However, these blocks are dependent; namely, we cannot solve them in parallel. We can start to solve a block only when all of the former blocks are solved. Note that the papers [49][50] proposed some methods to reduce the dependency and made a block can be solved when only some former blocks are solved. The details are omitted here. Since the jobs for solving triangular nim are dynamic generated, the jobs are suitable to be solved on job-level computation model.

4.4.2 Miscellaneous Issues

The first issue for discussion is that of overhead of job dispatching. In the job-level model, the client must wait passively for notification of idling workers. Thus, overhead is incurred for the round trip of notification. In practice, in the job-level system [59], one or more jobs are dispatched to the broker in advance, to keep all workers busy. Note that we do not dispatch a large number of jobs in advance for the reason mentioned in Section 1.

The second issue is that of distributed versus shared-memory. One key for our

job-level model is to leverage a game-playing program which can be encapsulated as a job to be dispatched to a worker remotely in a distributed computing environment. Distribution, however, means that some data, such as transposition tables, cannot be shared by different jobs. However, if the job supports several threads and the worker offers several cores, then the job can still be run with several threads on the worker in the job-level system.

The third discussion is that of the quality of game-playing programs. In our experiences of using JL-PNS, we observed that the quality of game-playing programs affects the total computation time significantly. In our earlier versions of NCTU6, we could not solve the Straight opening after a hundred thousand jobs, and solved the Mickey Mouse opening with many more than that. After we improved NCTU6 in later versions, the Straight opening, as well as many other positions, was solved, and the Mickey Mouse opening was solved with fewer jobs (almost half). On the other hand, JL-PNS or job-level search can be used to indicate the quality of game-playing programs.

The last issue is how to use the result of JL-PNS to build the openings. PNS is a best-first search algorithm mainly designed for proving or disproving positions. The problem is that if the positions cannot be solved by PNS, the result of PNS is hard to tell which move is the best move to play, since the pn/dn are designed to indicate how fast the position is to be proved/disproved. Thus, when we use JL-PNS to build the Connect6 opening, the positions which are proved or disproved can be easily added to the openings database. However, for the positions which are not proved or disproved yet, one of possible ways is to choose the move with the smallest ratio of pn and dn for black and the move with the biggest ratio of pn and dn for white. According to our experiences, this method is not perfect. This leaves as an open problem.

4.5 Conclusion

Generic job-level search can be used to leverage game-playing programs which are already written and encapsulated as jobs. In this chapter, we present and focus on a Job-Level Proof Number Search (JL-PNS), a kind of generic job-level search, and apply JL-PNS to solving automatically several Connect6 positions including some difficult openings. The advantages are as follows.

 This thesis proposes the job-level computation model. The benefits of job-level includes the following: develop clients and jobs independently, run jobs in parallel, maintain the generic search in the client, and monitor the search tree easily. The first also implies that it is easy to develop job-level search without extra development cost to the game-playing programs (like NCTU6).

 This thesis proposes a new approach, JL-PNS (job-level proof number search), to help solve the openings of Connect6.

 This thesis successfully uses JL-PNS to solve several positions of Connect6 automatically, including several 3-move openings in Figure 32. No Connect6 human experts were able to solve them. From the results, we expect to solve and develop more Connect6 openings.

 For JL-PNS, this thesis proposes some techniques, such as the method of postponed sibling generation and the policies of choosing MPNs.

 Our experiments demonstrated that the MF-VE policy performs best. Thus, it is recommended to use this policy to solve positions.

 Our experiments demonstrated an average speedup of 8.58 on 16 cores.

In addition to JL-PNS, we can apply the job-level model to other applications [60], such as JL-MCTS for Go and JL-ABS for Chinese chess.