The Startech Massively Parallel Chess Program Bradley C

The StarTech Massively Parallel Chess Program Bradley C. Kuszmaul [email protected] http://theory.lcs.mit.edu/Äbradley Laboratory for Computer Science Massachusetts Institute of Technology NE43-247, 545 Technology Square Cambridge, MA 02139 January 11, 1995

Abstract chess, the StarTech project has produced some interesting computer chess technology. This paper explains how The StarTech massively parallel chess program, running StarTech works and how it performs. on a 512-processor Connection Machine CM-5 supercom- The chess knowledge of StarTechÐwhich includes the puter, tied for third place at the 1993 ACM International opening book of precomputed moves at the beginning Computer Chess Championship. StarTech employs the of the game, the endgame databases, the static position- Jamboree search algorithm, a natural extension of J. Pearl's evaluation function, and the time-control strategyÐis Scout search algorithm, to ®nd parallelism in game-tree based on H. Berliner's Hitech program [BE89]. Hitech searches. StarTech's work-stealing scheduler distributes runs on special-purpose hardware built in the mid 1980's the work speci®ed by the search algorithm across the pro- and searches in the range of 100,000 to 200,000 positions cessors of the CM-5. StarTech uses a global transposition per second. Berliner provided me with an implementa- table shared among the processors. StarTech has an infor- tion of Hitech written in C (without any search extensions mally estimated rating of over 2400 USCF. except for quiescence with check extension) that runs at Two performance measures help in understanding the 2,000 to 5,000 positions per second. I built a parallel pro- performance of the StarTech program: the work, W , and gram using Berliner's serial code and reimplemented parts the critical path length, C . The Jamboree search algorithm of the serial program to make it faster. Both the serial and used in StarTech seems to perform about 2 to 3 times more parallel versions of my program are called StarTech. Star- work than does our best serial implementation. The critical Tech, unlike Hitech, does not use the null-move search, path length, under tournament conditions, is less than 0.1% which probably costs StarTetch about a factor of two in of the total work, yielding an average parallelism of over performance. StarTech uses the same search extensions in

1000. The StarTech scheduler achieves actual performance both the serial and the parallel implementations.

W P + C P of approximately T 1 02 1 5 on processors. I divided the programming problem into two parts: an The critical path and work can be used to tune performance application and a scheduler. The application can be thought by allowing development of the program on a small,readily of as a dynamically unfolding tree of chess positions. There accessable, machine while predicting the performance on are dependencies among the positions. A position may not a big, tournament-sized, machine. be searched until the positions it depends on have been searched. The application speci®es the shape of the tree 1 Introduction and the dependencies between the positions. The scheduler, on the other hand, takes such an application and de- Computer chess provides a good testbed for understanding cides on which processor each position should be evalu- dynamic multithreaded computations. The parallelism in ated, and when the evaluation should be done. The appli- computer chess is derived from a dynamic expansion of cation's job is to expose parallelism. The scheduler's job is a highly irregular game-tree, which has historically made to run the program as fast as possible, given the parallelism it dif®cult to implement parallel computer chess programs in the application. Thus, StarTech is conceptually divided and other dynamic applications. To investigate how to into two parts: The parallel game tree search algorithm program such applications, I engineered a parallel chess (the application), which speci®es what can be done in par- program called StarTech (pronounced ªStar-Tekº) on the allel; and the scheduler, which speci®es when and where Connection Machine CM-5. Even though my primary area the work will actually be performed. of research is in parallel computing rather than computer The remainder of this paper is organized as follows. Sec- tion 2 describes how StarTech works explaining the Jam- This research was supported in part by the Advanced Research Projects Agency (DoD) under Grants N00014-94-1-0985, N00014-92- boree game-tree search algorithm and sketching the imple- J-1310, and N00014-91-J-1698. mentation of the global transposition table. A performance

1 study, relating StarTech's performance to two fundamental nearly serial. When a processor discovers some work that measures of parallel performance,is presented in Section 3. could be done in parallel, it posts the work into a local Section 4 shows how I used those metrics to improve the data structure. When a processor runs out of work locally, performance of StarTech. Section 5 concludes with some it sends a message to another processor, selected at ran- remarks on the challenges of parallel computer chess. dom, and removes work from that processor's collection of posted work. The CM-5 has suf®cient interprocessor 2 How StarTech Works communications performance that there is no appreciable advantage in trying to steal locally rather than from a ran- Before examining the performance of StarTech in Sec- dom processor, and the randomized approach to scheduling tion 3, this section explains how StarTech works. First, is provably ef®cient [BL94]. an overall description of how StarTech searches in parallel is presented. Then, the Jamboree algorithm is ex- Scout Search plained, starting with a review of the serial Scout search algorithm. Next, the board-representation problem, which Before delving into the details of Jamboree search, let is faced by the implementors of any parallel chess program, us review the serial Scout search algorithm. For a parallel is illustrated by showing how the repeated-position test is chess program, one needs an algorithm that both effectively

implemented in StarTech. Finally the implementation of prunes the tree and can be parallelized. I started with StarTech's global transposition table is explained. a variant on serial - search, called Scout search, and StarTech's game-tree search algorithm is called Jam- modi®ed it to be a parallel algorithm. boree search. The basic idea behind Jamboree search is to Figure 1 shows the serial Scout search algorithm. (Many do the following operations on a position in the game tree chess researchers refer to the Scout algorithm as ªPV Searchº, but it appears that J. Pearl's ªScoutº terminology that has k children:

takes precedence [Pea80].) Procedure scout is similar to

The value of the ®rst child of the position is deter- the familiar - search algorithm which takes paramaters mined (by a recursive call to the search algorithm.) and used to prune the search [KM75]. The Scout al-

gorithm, however, when considering any child that is not

k Then, in parallel, all of the remaining 1 children the ®rst child, ®rst performs a test of the child to determine are tested to verify that they are not better alternatives if the child is no better a move than the best move seen so than the ®rst child. far. If the child is no better, the test is said to succeed. If the child is determined to be better than the best move so

Any children that turn out to be better than the ®rst child are sequentially searched to determine which is far, the test is said to fail, and the child is searched again the best. (valued) to determine its true value. The idea is that testing a position is cheaper than determining its true value. If the move ordering is best-®rst, i.e., the ®rst move consid- The Scout algorithm performs tests on positions to see ered is always better than the other moves, then all of the if they are greater than or less than a given value. A test is

tests succeed, and the position is evaluated quickly and ef- performed by using an empty-windowsearch on a position.

) () ®ciently. We expect that the tests usually succeed, because For integer scores one uses the values ( 1 and the move ordering is often best-®rst due to the application as the parameters of the recursive search, as shown on of several chess-speci®c move-ordering heuristics. Line (S9). A child is tested to see if it is worse than the This approach to parallel search is quite natural, and best move so far, and if the test fails on Line (S12) (i.e., variants of it have been used by several other paral- the move is better than the best move seen so far), then the lel chess programs, such as Cray Blitz [HSN89] and child is valued, on Line (S13), using a non-empty window

Zugzwang [FMM93]. Still others have proposed or to determine its true value.

+ =

analyzed variations of this style of game tree search If it happens to be the case that 1 , then

s [ABD82, MC82, Fis84, Hsu90]. My Ph.D. thesis [Kus94] Line (S13) never executes because s implies , provides a more complete discussion of how Jamboree which causes the return on Line (S11) to execute. Conse- search is related to other search algorithms. I do not claim quently, the same code for Algorithm scout can be used that Jamboree search is an entirely novel search algorithm, for the testing and for the valuing of a position. although some of the details of my algorithm are quite Line S10, which raises the best score seen so far accord- different from the details of related algorithms. Instead, I ing to the value returned by a test, is necessary to insure view the algorithm as a good testbed for understanding how that if the test fails low (i.e., if the test succeeds), then the to design scalable, predictable, multithreaded programs. value returned is an upper bound to the score. If a test were To distribute work among the CM-5 processors, Star- to return a score that is not a proper bound to its parent, Tech uses a randomized work-stealing approach, in which then the parent might return immediately with the wrong idle processors request work. Processors run code that is answer when the parent performs the check of the returned

n )

(S1) De®ne scout( as

(n)

(S2) If n is a leaf then return static eval .

(S3) Let c the children of , and

(c ) (S4) b scout 0 ;; Value

(S5) ;; The ®rst child's valuation may cause this node to fail high.

(S6) If b then return .

(S7) If b then set .

jcj

(S8) For i from 1 below do: ;; the rest of the children

s (c )

(S9) Let scout i 1 ;; Test

b b s

(S10) If s then set .

(S11) If s then return . ;; Fail High

(S12) If s then ;; Test failed

s (c )

(S13) Set scout i . ;; Research for value

(S14) If s then return . ;; Fail High

(S15) If s then set .

b b s (S16) If s then set . (S17) enddo

(S18) return b.

Figure 1: Algorithm scout.

score against on Line S11. and abort any of the children that are still running. Such

A test is typically cheaper to execute than a valuation be- an abort is needed when the procedure has found a value cause the - window is smaller, which means that more that can be returned, in which case there is no advantage of the tree is likely to be pruned. If the test succeeds, to allowing the procedure and its children to continue to then algorithm scout has saved some work, because test- run, using up processor and memory resources. The abort ing a node is cheaper than ®nding its exact value. If the causes any children that are running in parallel to abort their test fails, then scout searches the node twice and has children recursively, which has the effect of deallocating squandered some work. Algorithm scout bets that the the entire subtree. tests will succeed often enough to outweigh the extra cost Parallel search of game-trees is dif®cult because the most of any nodes that must be searched twice, and empirical ef®cient algorithms for game-tree search are inherently evidence [Pea80] justi®es its dominance as the search algo- serial. We obtain parallelism by performing the tests in rithm of choice in modern serial chess-playing programs. parallel, but those tests may not all be necessary in a serial execution order. In order to get any parallelism, we must Jamboree Search take the risk of performing extra work that a good serial program would avoid. By taking our chances with the The Jamboree algorithm, shown in Figure 2, is a paral- tests rather than the valuations, we minimize the risk of lelized version of the Scout search algorithm. The idea is performing a huge amount of wasted work. that all of the testing of the children is done in parallel, and any tests that fail are sequentially valued. A paral- Copying Data for Parallel Search lel loop construct, in which all of the iterations of a loop run concurrently, appears on Line (J7). Some synchro- Most serial chess programs use data structures that make nization between various iterations of the loop appears on them dif®cult to parallelize. For example, a typical se- Lines J12 and J18. The Jamboree algorithm sequentializes rial program uses many global variables. Every time a the full-window searches for values, because, whereas we subsearch is started the global variables are modi®ed, and are willing to take a chance that an empty window search when the subsearch ®nishes, the modi®cations to the global will be squandered work, we are not willing to take the variables are undone. This approach ef®ciently supports chance that a full-window search (which does not prune board representations that are large, as long as relatively very much) will be squandered work. Such a squandered few bytes change on any given move. It can be dif®cult to full-window search could lead us to search the entire tree, parallelize a program written in this style, however, since which is much larger than the pruned tree we want to when a steal-request arrives, there is no explicit represen- search. tation of the boards that need to be stolen from the middle The abort-and-return statements that appear on Lines of the search tree. J10 and J15 return a value from Procedure jamboree StarTech addresses this problem by copying the board

n )

(J1) De®ne jamboree( as

(n)

(J2) If n is a leaf then return static eval .

(J3) Let c the children of , and

(c )

(J4) b jamboree 0

(J5) If b then return .

(J6) If b then set .

jcj

(J7) In Parallel: For i from 1 below do:

s (c )

(J8) Let jamboree i 1

b b s

(J9) If s then set .

(J10) If s then abort-and-return .

(J11) If s then (J12) Wait for the completion of all previous iterations

(J13) of the parallel loop.

s (c )

(J14) Set jamboree i . ;; Research for value

(J15) If s then abort-and-return .

(J16) If s then set .

b b s (J17) If s then set .

(J18) Note the completion of the ith iteration of the parallel loop. (J19) enddo

(J20) return b.

Figure 2: Algorithm jamboree. state when a subsearch is started. Thus, when a child The Global Transposition Table completes, the parent still has its original, unmodi®ed, copy of the board, and therefore no ªunmodifyº needs to StarTech, like most chess programs, uses a transposition be done. When the board is copied, however, every byte table to cache results of recent searches. For a search from of the board representation must be copied, whether it is a given position to a certain depth, the transposition table modi®ed or not. indicates the value of the position and the best move for that position. The transposition table is indexed by a hash key The board state can include some things that one might derived from the position. Whenever the search routine not expect. Consider the problem of detecting repeated po- ®nishes with a position, it modi®es the transposition table sitions. Most serial programs use a hash table that stores by writing the value back. (It may decide that the old value all the positions in the game history and the variation lead- stored was better to keep than the new value.) Whenever ing to a particular position. The hash table can be incre- the search routine examines a position, the routine ®rst mentally modi®ed and unmodi®ed. Somehow the set of checks to see if the position's value has been stored in the previous positions must be represented in the board state. transposition table. If the value is present, then the routine can simply return the value. Sometimes, the value for the StarTech represents the positions in the variation with an position is not present, but a best move is present for a array of hash keys (one key for each position.) This array search to a shallower depth. In this case the best move of positions can be thought of as the part of the board- for the shallow depth can be used to improve the move state. (The entire game is broadcast to all the processors, ordering. Since the Jamboree search algorithm depends so that the processors are able to examine the positions in on good move ordering, the transposition table is very the actual game without copying those positions repeat- important to the performance of StarTech. edly.) When a position is stolen, the sequence of positions between the root of the search tree and the stolen position Program StarTech uses a global transposition table dis- is sent through the data network to the stealing processor. tributed across all the nodes of the machine, as shown in Figure 3. To access the transposition table, which requires The cost of copying the move history is not as great communicating from one node to another, a message- as one might expect. Only the hashes of the positions passing protocol is used. The hash key used to index encountered since the last irreversible move need to be the table is divided into two parts: a processor number and copied. In StarTech, the average length of the repeated- a memory offset. When a processor needs to look up a position history that is actually copied is less than one, position in the table, it sends a message to the processor partly because in quiescence search most of the moves are named by the hash key, and that processor responds with a irreversible. message containing the contents of the table entry. (A sim-

4 Hash Key processor memory offset collision resolution bits

Globally Distributed Transposition Table

M2097152

Memory

Offset M4 M3 M2 M1 M0

P0 P1 P2 P3 P4 P5 P512

Processor

Table element collision resolution bits search depth best move lower bound upper bound

Figure 3: The Startech transposition table is globally distributed. The hash key for a position is divided into a processor number, memory offset, and collision resolution bits. The processor number and memory offset identify a unique table element in the machine. The collision resolution bits discriminate between positions that map to the same table element. The table element contains the depth to which the tree was searched, the best move, a lower bound to the value of the position, and an upper bound to the value of the position. ilar transposition table scheme is used by the Zugzwang Estimating StarTech's Rating parallel chess program [FMM93].) The most common questions about StarTech's performance Historically parallel chess programs have often avoided are ªWhat is StarTech's Rating?º and ªHow much real per- global transposition tables. F. Popowich and T. Marsland formance improvement does StarTech get by using more concluded that local transposition tables are better than processors?º This section attempts to answer those ques- global transposition tables [PM83]. Local transposition tions. The standard way to determine the rating of a chess tables do not incur any message-passing overhead, but lo- player is to play lots of games. Since playing games is cal transposition tables have a much lower hit rate than very time consuming, I use a set of benchmark prob- global transposition tables. With message passing over- lems designed by I.M. L. Kaufman [Kau92, Kau93] to heads that measure in the tens of milliseconds, Popowich estimate StarTech's performance using the Elo rating sys- and Marsland were forced to choose between bad perfor- tem [Elo78]. Kaufman cautions against misuse of his rat- mance due to message-passing costs, or bad performance ings estimator, for example by tuning a program to do well due to poor transposition table effectiveness. The decision against only the benchmark problems. Since StarTech has is much easier for StarTech, which uses low-overhead (10 not been tuned against Kaufman's benchmark, we can get microsecond) messages on the CM-5. (Similarly, Cray some idea of StarTech's rating by using Kaufman's esti- Blitz uses a global transposition table because accessing mator. global memory is also inexpensive on a Cray supercom- To obtain an estimated Elo rating for a program, Kauf- puter [HSN89].) man uses 25 chess positions (20 tactical, 5 positional), each of which has a correct answer. To obtain an estimated rat- 3 The Performance of StarTech ing, one measures the time it takes for the program to ®nd Kaufman's correct answer for each position. Then, one The previous section explained how StarTech works. This throws away the worst 5 times and sums up the remaining section explores the performance of StarTech. We start times. Let t20 be the sum of the times, in seconds, to solve by estimating StarTech's rating using a ratings estimation the fastest 20 positions. Given t20, Kaufman estimates the benchmark. Then, by using two fundamental parallel per- USCF rating as

formance metrics, the work and the critical path length, we

t USCF Rating 2930 200 log (1) gain a deeper understanding of StarTech's performance. 10 20 Finally, we present a few analytical results on the Jam- which means that a factor of 10 in performance is estimated boree search algorithm. to be worth 200 ratings points. In addition to looking at

5 Trans- Positions Time Estimated Processors Time for Estimated Time for position Visited (seconds) Rating Top 20 Rating all Table top 20 (seconds) (USCF) (seconds) Entries 1 8936.95 2139 38261.91 0 161,625,376 23337.14 2056 2 5376.45 2183 22007.46 216 94,409,196 13506.36 2104 4 3152.54 2230 11614.43 217 85,753,262 12670.01 2109 8 1932.27 2272 7411.54 218 76,498,040 10925.46 2122 16 1240.72 2311 4398.32 219 65,568,814 9605.36 2133 32 844.00 2344 2803.33 220 55,910,651 8040.08 2149 64 573.19 2378 1670.29 221 48,256,980 7138.08 2159 128 444.78 2400 1129.68 222 42,627,585 5799.31 2177 256 378.72 2414 907.24 223 40,805,974 6120.18 2173 512 319.38 2429 677.11 224 40,805,974 6364.99 2169 Figure 5: The estimated rating of our parallel implemen- Figure 4: Performance of my best serial implementation tation of Startech as a function of the number of pro- of StarTech as a function of transposition table size. The cessors. The time to solve the fastest 20 of Kaufman's number of chess positions in the search tree is shown, test problems is shown, along with the estimated rating along with the time in seconds, and, the estimated rating (computed with Equation 1), and the time to solve all 25 using Kaufman's ratings estimation function, given by positions. Equation 1. 222 entries or smaller easily ®t within the main memory of the fast 20 positions, I also ®nd it interesting to look at the the serial computer I used. sum of the times for all 25 positions. I ran Kaufman's test on a variety of different CM-5 con- I wanted to measure the improved rating of StarTech ®gurations. Each con®guration includes a transposition as a function of the number of processors, but ®rst I had table of with at least 226 entries total. The transposition to isolate other factors. The biggest other factor is the table size was set at 221 entries per processor, which is the effect of the transposition-table size which varies with the largest size that ®ts in the 32 Megabyte memory of the number of processors. CM-5 processors. For runs on fewer than 32 processors, Hsu argues [Hsu90] that if one increases the size of the I actually used a 32-processor machine with some proces- transposition table along with the number of processors, sors `disabled'. In this case, I used the entire distributed then the results are suspect. Hsu states that increasing memory of the 32-processor machine to implement the the transposition table size by a factor of 256 can easily global transposition table. As a result, in every parallel improve the performance by a factor of 2 to 5. My strategy run, the transposition table contains a total of at least 226 is to choose a transposition table size that is suf®ciently entries. large that increasing it further doesn't help the performance on this benchmark. Figure 4 shows the estimated rating of Figure 5 shows the estimated rating of Startech as a the serial program as a function of the transposition table function of the number of processors. According to Kauf- size, and it also shows the number of positions visited by man's test, there is a diminishing return as the number of the program under each con®guration. processors increases when only the fastest 20 problems are Note that the number of positions visited by the search considered. If we consider the time to solve all 25 prob- tree monotonically decreases as the table gets larger, but lems, however, there are still signi®cant performance gains that after 223 entries, the number of positions becomes being made even when moving from a 256-node CM-5 to constant. We can conclude that for Kaufman's ratings test 512-nodes. any transposition table size of more than 223 entries is quite Several other chess problem sets have appeared in the suf®cient, and a larger transposition table will not, by itself, literature to test the skill of a chess program. The Bratko- raise the estimated rating of the program. Kopec set [KB82], one of the earliest test sets published I believe that the slight decrease in estimated rating (i.e., for computers, was designed to show the de®ciencies of the increase in time to solve the problems) beyond 223 a program rather than to estimate the program's strength. entries is due to paging and cache effects, because the Feldmann et al. [FMM93] found that the Bratko-Kopec machine I ran these tests on could not reliably hold the test set could not differentiate between master-level chess working set in main memory when the transposition table programs, and so they picked a collection of positions from is larger than 223 entries. Any transposition table of size actual games they had played to measure the performance

6 of their program. Kaufman's problem set was speci®cally be salvaged from a program with these characteristics? designed to estimate the rating of a program that plays I found that two numbers, the critical path length and the master-level chess. work, can be used to predict the performance of StarTech.

Even Kaufman's problem set is not dif®cult enough to The critical path length C is the time it would take for the test a program like StarTech. Partly this is because Star- program to run on an in®nite-processor machine with no Tech inherits HiTech's strategy of analyzing a position for scheduling overheads. It is a lower bound on the runtime

a few seconds before starting the search, and partly be- of the program. It turns out that C can be measured as cause it takes the parallel search routine a few seconds the program runs, by a method of timestamping, without to expose any parallelism. StarTech wants problems that actually performing an in®nite-processor simulation. The

will take more than just a few seconds to solve. On the work W is the number of processor cycles spent doing

512-processor run, for many of Kaufman's positions, the useful work. W does not include cycles spent idle when

program spends only a few seconds on the position. On there is not enough work to keep all the processors busy. W P

average the time spent on the fastest 20 moves is only On P processors, I de®ne to be the linear speedup W P

16 secondsÐless than a tenth of the time allowed un- term. Both C and are lower bounds to the runtime

C W der tournament time conditions (roughly 180 seconds per on P processors. (Another way to think about and

move.) The positions in Kaufman's test that achieve the is to consider the program to be a data¯ow graph. C is

best speedup are often discarded by Kaufman's evaluation the depth of the graph, and W is the size of the graph.) T scheme because they were among the slowest ®ve posi- W

We can compare to S , the runtime of a corresponding W

tions. In tournament play, StarTech's performance, mea- serial chess program, and we can compare C to . The W sured in positions per second, is generally much better in T

ratio S is the ef®ciency of the parallel program, and the second 90 seconds of a search than during the ®rst 90 indicates how much overhead is inherent in the parallel

seconds of search. Under such conditions, StarTech seems algorithm. The ratio W C is the average parallelism of to achieve a factor of between 50 and 100 speedup on 512 the program, and indicates how many processors we can

processors. hope to effectively use. A good application keeps W and

C W

The authors of the Zugzwang chess program [FMM93] C small. Usually, I simply measure and as the W encountered similar problems, ®nding that when search- program runs. The values for C and can also be derived ing `easy' positions to a very deep depth, more speedup analytically for a few special cases.

is achieved than can realistically be expected under tour- C For many non chess applications the values of W and nament conditions. On the other hand, searching the easy depend only on the application, rather than on the sched- problems to a shallow depth does not give the program an uler. In StarTech's search algorithm, however, the values

opportunity to ®nd parallelism. C of W and are partially dependent on decisions made

In summary, I found it dif®cult to obtain a clear estimate C by the scheduler. I found that W and seem to be, in of the strength of StarTech from these benchmarks, but it practice, mostly independent of those decisions. appears safe to say that StarTech's rating would be over It is easy to measure the work of a program. I mea- 2400 USCF. An effort needs to be made to ®nd harder sured, using the microsecond-accurate timers of the CM-5, problems to test parallel programs. the total number of cycles spent running chess code on each processor. Figure 6 shows how the measured work Critical Path and Work of StarTech varies with the machine size for each of several executions Simply measuring the runtime of StarTech does not provide of each of the 25 chess positions. The time for solving much insight into why the program behaves as it does. We the problem on my best serial version of StarTech is also now examine how to use two fundamental performance shown. Note that the amount of work increases (that is, the metrics, critical path and work, to better understand the ef®ciency drops) as the machine size grows. (It turns out performance of StarTech. that StarTech always runs faster on a big machine than on It was not clear to me, when I started programming Star- a small machine, however.) Whereas the ef®ciency drops Tech, how to predict the performance of a parallel chess as the machine gets larger, if we ®x the machine size, and program. Chess programs search a dynamically generated let problems run longer, the ef®ciency improves. (The tree, and obtain their parallelism from that tree. Differ- longer running positions are shown ®rst, and they are the ent branches of the tree have vastly different amounts of positions on which less extra work is done by bigger ma- total work and average parallelism. Chess programs use chines.) Jamboree search achieves ef®ciencies of between large global data structures and are nondeterministic. I 33% and 50%. wanted predictable performance. For example, if I de- The critical path length is a little bit more dif®cult to velop a program on a small machine, I would like to be measure. Using the CM-5 timers, I measured the length able to instrument the program and predict how fast it will of the longest dependency chain of each tree, as the search run on a big machine. How can predictable performance runs. (The measurement is performed as follows: Each po-

7 sition's critical-path depth is de®ned to be the maximum search to depth 10, a best-ordered chess tree would have of the critical path depths of the positions it depends on, several hundred-thousand fold parallelism. plus the time it takes to do move generation and static eval- If the tree is not best-ordered,then the performance of the uation on that position.) Figure 7 shows how the measured parallel algorithm can be much worse,however. Theorem 2 critical path length varies with the machine size for each of addresses worst-ordered trees. A worst-ordered tree is one 25 different chess positions. The critical path also varies in which the worst move is considered ®rst, and the second with the machine size because search algorithm interacts worst move is considered second, and so on, with the best with the scheduler. move considered last. The critical path and work can actually be used to predict

Theorem 2 For uniform worst-ordered trees of degree d

the performance of StarTech. I found that the run-time on and height h, the ef®ciency is about 1 3 and the average

P processors of StarTech is accurately modeled as parallelism is about 3, and the speedup is always less

W than 1.

T C + +

P 1 02 1 5 4 3 seconds. (2)

P Surprisingly, for worst-ordered uniform game trees, the Except for the constant term of 4.3 seconds, this estimate is speedup of Jamboree search over serial - search turns out

within a factor of 2.52 of the lower bounds given by C and to be under 1. That is, Jamboree search is worse than serial

W P . The 4.3-second constant term comes from the time - search, even on an ªidealº machine with no overhead StarTech spends at the beginning of every search analyzing for communications or scheduling. For comparison, paral- the board and initializing the evaluation tables. lelized negamax search achieves linear speedup on worst- The scheduler and the Jamboree algorithm have positive ordered trees, and Fishburn's MWF algorithm achieves interactions. Abstractly, the scheduler and the algorithm nearly linear speedup on worst-ordered trees [Fis84]. are separated. But in practice, there are interactions be- In summary, critical path and work are the important pa- tween them. If there is more parallelism than there are rameters for understanding the performance of StarTech. processors, then processors tend to do their work locally, The average parallelism and ef®ciency of StarTech are both effectively creating a larger grain size, and the ef®ciency of good enough to achieve signi®cant speedup on chess prob- the underlying serial algorithm becomes the determining lems, which probably allows StarTech to performs at Se- performance factor. The StarTech scheduler attempts to nior Master level. steal work that is near the root of the game tree, rather than work that is near the leaves. By stealing work near the root 4 Improving StarTech of the game tree, the size of stolen work is increased. On the other hand, if work is stolen that later is determined not We have seen how StarTech works, and some basic perfor- to have been useful, more processor cycles are wasted. I mance characteristics of the program. This section shows found that for a given tree search, the average size of stolen how the critical path and work can be used to improve the work is larger for smaller machines. performance of StarTech. First we look at a traditional pro- ®le of how time is spent by StarTech, and then we review Analysis of Jamboree Search three strategies that I found can improve the performance of the program. The Jamboree search algorithm can be analyzed for a few special cases of trees of uniform height and degree. It How Time is Spent in StarTech turns out that I have two analytical results, one for best ordered trees and one for worst ordered trees. The complete Examining a timing pro®le can provide clues for how to statement of the theorems and proofs can be found in my improve a program. Figure 8 shows how the processor Ph.D. thesis [Kus94]. cycles are spent by StarTech on a typical chess position Theorem 1 states how Jamboree search behaves on best- that ran for about 100 seconds on a 512-processor machine. ordered trees. A best-ordered tree is one in which it turns The biggest chunk of time is devoted to the chess-work, out that the ®rst move considered is always the best move, which further broken down in Figure 9. and thus the tests in the jamboree search algorithm always More than a third of all the processor cycles, and more succeed. than half the cycles spent by on `chess work' are spent by the code that implements the control ¯ow of the Jam-

Theorem 1 For uniform best ordered trees of degree d and boree algorithm. In my serial program, the control ¯ow

height h, the ef®ciency is 1, and the average parallelism is of the - search algorithm consumes about a quarter of

h )

( 2

d ) about ( 2 . all the processor cycles. The biggest potential improvement is to improve the code that executes the Jamboree Chess trees typically have degree between 30 and 40 in search, although I have not been able to ®nd any obvious the middle-game, and which means that on a full-width improvements to the code.

8 k01 k04 k07 k02 k24 32482.6 25874.1 31099.0 22133.7 15045.7