2009 ACCA World Computer Rapid Chess Championships

[sje]

After the conclusion of each game in the event, I'll upload Symbolic's log file for the game to the net for others to download. Symbolic logs include all xboard/engine traffic and all analysis, and each entry is UTC timestamped. This is done in the spirit of openness, and I invite other authors to do the same.

Bookmark: http://idisk.mac.com/chessnotation-Public?view=web

I've placed a sample logfile in the "Logs" folder as a preview.

[sje]

For some unknown reason, my uploads to the above net directory are appearing with file timestamps set twelve hours in the future. Spooky, eh? Anyway, I have nothing to do with this and I hope it's fixed soon.

By the way:

1) Symbolic's current ICC Standard rating is about a hundred points higher than is the one appearing on the TACCL site. If I can get the multithread search implemented in time, the rating should be even higher. How much higher? Going from one core to four cores should be good for another hundred points, I'd guess.

2) It is possible that the program might be running on a small (ten core) cluster by the time of the tournament instead of a single machine.

3) The current opening book has 847,192 moves. This may change by the time of the event.

[Zach Wegner]

2) It is possible that the program might be running on a small (ten core) cluster by the time of the tournament instead of a single machine.

Good luck!

[sje]

2) It is possible that the program might be running on a small (ten core) cluster by the time of the tournament instead of a single machine.

Good luck!

The main difficulty with a heterogeneous distributed search is not coding the communication, but rather managing load balancing. If a distributed search spends too much time waiting for slower machines to respond, then any benefits of having extra processors are lost.

[Zach Wegner]

2) It is possible that the program might be running on a small (ten core) cluster by the time of the tournament instead of a single machine.

Good luck!

The main difficulty with a heterogeneous distributed search is not coding the communication, but rather managing load balancing. If a distributed search spends too much time waiting for slower machines to respond, then any benefits of having extra processors are lost.

If you think you can go from a single processor search to a multiprocessor distributed search in a matter of a few weeks, I must repeat myself: good luck. If it works at all, don't expect it to work well. Just saying you would have machines "waiting for others to respond" shows you're going to have some major inefficiencies to deal with.

What sort of algorithm are you planning, for both multiprocessor and distributed search?

[sje]

The main machine keeps a search task (thread) status board. When a search thread wants to split, it consults this board for a free thread. If/when one is found, the idle thread is used as a target for a simple function call with the position, the window, the starting ply, the fractional depth, and a returned PV move list. It doesn't matter if the thread is local or remote, but the choice of thread may be dependent on the speed of the call, to amount of work to be done, and the target machine. As there is some overhead here, there is a lower bound on the allowable fractional depth.

The details of managing the central status board and when to split are kept private at the moment as they are very likely to change with testing. A big concern here is how to efficiently handle the possibility of a network failure or remote failure without the need to restart the search or the program.

[CRoberson]

2) It is possible that the program might be running on a small (ten core) cluster by the time of the tournament instead of a single machine.

Good luck!

The main difficulty with a heterogeneous distributed search is not coding the communication, but rather managing load balancing. If a distributed search spends too much time waiting for slower machines to respond, then any benefits of having extra processors are lost.

If you think you can go from a single processor search to a multiprocessor distributed search in a matter of a few weeks, I must repeat myself: good luck. If it works at all, don't expect it to work well. Just saying you would have machines "waiting for others to respond" shows you're going to have some major inefficiencies to deal with.

What sort of algorithm are you planning, for both multiprocessor and distributed search?

You are not factoring in experience. My first parallel coding effort was in 1984. I have a distributed version of Telepath running that took me
two weeks. The last week was mostly tweaking and tuning. I am still tuning but it is running.

I expect Steve's experience is sufficient to produce a distributed version of Symbolic in 2 weeks. Tuning takes longer.

Telepath may be running on a small cluster in WCRCC. Likely an ad hoc one.

[Zach Wegner]

It's not about experience, it's about efficiency. I think you, Steven, and myself could all produce a basic distributed search in a few weeks time. But doing a full YBW-like approach that acts similarly to a shared memory search is significantly more complicated. If experience was the main factor here, Bob would already have a fully working distributed search. He's been preparing quite a while, as I have, and as far as I know he's still in the design phase. That doesn't mean he's a crappy programmer of course, just that he knows what he's getting into and wants to do it right.

Anyways, I've been working on my distributed search pretty solidly for the past week or so and it's nearing a working point. Then comes an endless amount of tuning. Before that most of the work was spent designing and building in some of the infrastructure (network/message code etc). I'd like to play with it in the WCRCC but I certainly won't have everything ready for it. I'll probably just end up playing ZCT on an octal.

Also, what's your distributed search like? What algorithm are you using? Last I knew you didn't have a multiprocessor search, which is significantly easier.

[sje]

Also, what's your distributed search like? What algorithm are you using? Last I knew you didn't have a multiprocessor search, which is significantly easier.

The MT search is running, but not yet on an ICS. And as I wrote earlier:

The details of managing the central status board and when to split are kept private at the moment as they are very likely to change with testing.

For the record, my multicore and distributed programming experience goes back to the mid to late 1970s using a CDC 6500 (a pair of CDC 6400 CPUs sharing memory). That's not as far back as Bob's early Cray experience, but close.

[Zach Wegner]

Also, what's your distributed search like? What algorithm are you using? Last I knew you didn't have a multiprocessor search, which is significantly easier.

The MT search is running, but not yet on an ICS.

That question was for Charles.