Computer draughts tournaments

[Ed Gilbert]

Is there an announcement of the next 10x10 draughts tournament at Culemborg? I tried a Google search but could not find anything. Thanks.

-- Ed

[BertTuyt]

Ed, think in December we have the next tournament.
But the best thing to do is to contact Leo Nagels as he is one of the organizers.
Here is his email address : lnagels@planet.nl

Bert

[FeikeBoomstra]

Heerlen, 16 september 2007


To whom it may concern:



Preliminary announcement for the open Dutch championship rapid Polish Draughts for computerprograms 2007.

Day of the tournament: Sunday the 2nd of December 2007.

Location: PW Consulting, Stationssingel 25 Culemborg, The Netherlands.

Time: 09:30 Installing the hardware, 10.00 Start first round.


Rules will be the same as during the tournaments of recent date (last year we played 9 rounds with playing-time 15 minutes per round per participant; after 75 moves arbitration if necessary).
Jaap Bus will again be the referee.


If you want to participate, please report by answering this e-mail.
Please report your participation before the 15th of November.



Fr gr,



Leo Nagels
Tel. 0031455721741
E-mail: lnagels@planet.nl

[TAILLE]

Hello,
I informed Leo Nagels that I am interested to participate to Culemborg tournament.
Who is also also intending to participate ?
Gérard

[Ed Gilbert]

Hello,
I informed Leo Nagels that I am interested to participate to Culemborg tournament.
Who is also also intending to participate ?
Gérard

Hi Gerard,

I am considering attending, but I will not make a firm decision until I return from vacation in a couple of weeks.

I found in the tournament rules that it is not permitted to adjust the program's game clock during a game. This means that you have to allow some operator time to enter the opponent's move into your program, and then to make your move on the table board and punch the table clock. How many seconds per move do you suppose that will take? :-) I can imagine this might take 3 to 5 seconds per move. If you estimate too little then your program can run out of time and you lose the game. If you estimate conservatively then maybe half of your total time cannot be used for searching!

Does anyone have a recommendation for a hotel that is convenient to the tournament site?

-- Ed

[TAILLE]

Hello,
I informed Leo Nagels that I am interested to participate to Culemborg tournament.
Who is also also intending to participate ?
Gérard

Hi Gerard,

I am considering attending, but I will not make a firm decision until I return from vacation in a couple of weeks.

I found in the tournament rules that it is not permitted to adjust the program's game clock during a game. This means that you have to allow some operator time to enter the opponent's move into your program, and then to make your move on the table board and punch the table clock. How many seconds per move do you suppose that will take? I can imagine this might take 3 to 5 seconds per move. If you estimate too little then your program can run out of time and you lose the game. If you estimate conservatively then maybe half of your total time cannot be used for searching!

Does anyone have a recommendation for a hotel that is convenient to the tournament site?

-- Ed

For the operator time I do not take into account, in my estimation, the time for punching table clock because it is compensate by the fact that we can enter the opponent move just after it had been played on the board (we have no to wait until the opponent punching the table clock).
For Damy I use 3s for the operator time i.E. 3'45" for 75 moves.
Gérard

[Ed Gilbert]

If anyone is interested, there is a short writeup about my experience in Culemborg at the kingsrow web site. http://pages.prodigy.net/eyg/Checkers/KingsRow.htm

-- Ed

[TAILLE]

If anyone is interested, there is a short writeup about my experience in Culemborg at the kingsrow web site. http://pages.prodigy.net/eyg/Checkers/KingsRow.htm

-- Ed

Hi Ed,

Congratulation for your victory. Kingsrow is already a very strong program and I will be very happy to meet you again in the future.
I hope you enjoyed your trip in Europe.
Gérard

[Ed Gilbert]

Hi Gerard,

Thank you, and it was a great pleasure to meet you and the other programmers in person. I expect to attend some future tournaments, although probably not a large number of them as it is quite an expensive and time consuming trip.

As we discussed on Sunday, I encourage you to look at the DamExchange library that Frank has created. It makes it very easy to add this feature to your program. With this we could automate an informal series of games over the internet. I expect that this would be very useful to both of us for improving our engines.

-- Ed

[BertTuyt]

Ed, congratulations with your victory.
I consider this an extraordinary result, participating for the first time with a new program in a 10x10 setting, and then reaching for number 1 !!!
I hope we will meet in the future.
In the mean time i work on the new version of Damage.
Im now working to get it working on a quad-core machine, and so far it is not easy to get the parallel algorithm working.
Nevertheless i hope that in 2008 the new Damage engine is ready to participate in tournaments again.

Im curious what the effect was on the endgame databases you used, as most programs nowadays only have 6-man databases.
Could you share with us, for example, where your program in the games Kingsrow played already saw draw or win.
Thanks in advance, and i think it is a good proposal do do some tests via the internet in the future (i will adopt my GUI for this reason and distribute it amongst people who are interested).

Bert (former champion)

[Ed Gilbert]

Hi Bert,

I was disappointed when I heard that you were not able to attend this time. But I'm sure we will get to meet at one of these tournaments and then I'll look forward to seeing your new multi-threaded version of Damage.

Im curious what the effect was on the endgame databases you used, as most programs nowadays only have 6-man databases.
Could you share with us, for example, where your program in the games Kingsrow played already saw draw or win.

I don't have time to do this tonight, but perhaps I can review the games this weekend and then post something. It's hard to say exactly how much effect the databases have. They are having an effect well before the search actually returns a database draw or a database win. I can tell you that in Kingsrow's game against TD King, Kingsrow played badly and allowed TD King to get it into a 4x3 side cramp. Kingsrow's search scores were dropping, and then all of a sudden it snapped to database draw -- phew! It sees the database draw on the search at move 48. when it moved 26-31. There are 14 pieces remaining on the board at that point in the game. TD King continued to see scores significantly in its favor for a number of additional moves. I don't remember now what Ton was using for endgame databases. It's possible that Kingsrow might have drawn that game using smaller databases, I haven't checked, but the large databases were certainly useful in that instance.

Here's the game against TD King.

[Event "Culemborg 2007, Round 4"]
[White "TD King"]
[Black "Kingsrow"]
[Result "1/2-1/2"]
1. 32-28 17-22 2. 28x17 12x21 3. 37-32 7-12 4. 34-29 20-25 5. 41-37 1-7 6. 31-26 14-20 7. 26x17 12x21 8. 33-28 7-12 9. 40-34 21-26 10. 32-27 10-14 11. 45-40 5-10 12. 28-23 19x28 13. 29-24 20x29 14. 34x32 11-17 15. 39-34 13-19 16. 38-33 15-20 17. 50-45 9-13 18. 44-39 10-15 19. 42-38 3-9 20. 27-21 16x27 21. 32x21 19-23 22. 21-16 14-19 23. 37-32 17-22 24. 32-27 22x31 25. 36x27 12-17 26. 46-41 17-22 27. 41-36 22x31 28. 36x27 2-7 29. 38-32 6-11 30. 33-28 7-12 31. 16x7 12x1 32. 39-33 9-14 33. 47-42 4-9 34. 42-38 1-6 35. 43-39 20-24 36. 49-43 15-20 37. 34-30 25x34 38. 39x30 23-29 39. 30-25 29-34 40. 40x29 18-23 41. 29x18 13x31 42. 32-27 31x22 43. 28x17 9-13 44. 48-42 8-12 45. 17x8 13x2 46. 45-40 2-8 47. 40-34 8-13 48. 34-30 26-31 49. 42-37 31x42 50. 38x47 13-18 51. 47-42 6-11 52. 33-28 11-17 53. 42-37 18-23 54. 37-32 17-21 55. 28-22 24-29 56. 30-24 19x30 57. 35x15 21-26 58. 25-20 14x25 59. 15-10 26-31 60. 32-27 31-36 61. 10-5 29-34 62. 5x28 34-40 63. 28-46 25-30 64. 22-18 40-45 65. 18-13 45-50 66. 13-9 30-35 67. 9-3 35-40 68. 3-20 50-45 69. 20-33 45-50 70. 43-39 40-44 71. 33-47 44x33 72. 47x29 50-45

-- Ed

[BertTuyt]

Ed, i also replayed the game TD King - KingsRow.

You are right, score for KingsRow was really dropping to an extend, that one should worry.
Using 6-man databases, and allowing 20s - 30s search on a AMD 3200+ machine ( 1 core only), Damage found also Draw but somehwat later at move 53 42-37. So i guess your databases have an advantage.

Are you planning to go beyond the 5m x 4m database (did you actually use this during tournament?) ?

In the mean time i try to get the Quad Core (2.4 Ghz Intel) working.
My parallel algorithm now works without having obvious problems. As a test i played a game against Truus. She lost 1 man but could survive the endgame, which proves me i'm on the right way.
Nevertheless, the parallel algorithm ( i go for YBWC) is not faster then the sequential one.

I guess much is related to the fact i don't use a shared hashtable, as locking really slows down the program (maybe go for a lockless implementation such as Hyat has proposed). Also multilock did not bring much either, guess im doing something wrong here.

What hardware did you use during the tournament?
And do you have the same horror experiences with parallel processing.

Note: On my QX6600 (Quadcore Intel at 2.4 Ghz) i now reach 6M Nodes /second, which make it possible to do a 15 Ply search within 20-30 seconds.


Bert

[Ed Gilbert]

Hi Bert,

Are you planning to go beyond the 5m x 4m database (did you actually use this during tournament?) ?

There is some basic information about Kingsrow International at this link: http://pages.prodigy.net/eyg/Checkers/Culemborg2007.htm. This will answer your question about databases used in the tournament. As to going further, I think if I do anything additional it would be to compute the full 8-piece db, but I have not decided to do that yet. I think I can do that using a single quad-core machine and that it would take between 12 and 18 months. But the 8-piece slices that I have now are the most useful ones. As Schaeffer has said about building partial databases, it gives you 50% of the power for 1% of the effort.

I am interested in making Kingsrow multi-threaded also. It sounds like you are making good progress. I expect that a shared hashtable using the lockless scheme described by Hyatt is the right method to use. His lockless idea is very clever yet simple, and requires almost no overhead. The YBW algorithm seems to be the method of choice among the chess programmers. IIRC the chess programs are getting search speed improvement greater than 3X when using quad core processors.

When you wrote "Nevertheless, the parallel algorithm ( i go for YBWC) is not faster then the sequential one.", do you mean that your multi-thread search is not faster in nodes/sec than a single thread version? You also wrote that you are able to reach 6M nodes/sec. Does that mean your single thread search normally searches at this speed? Kingsrow hits a maximum speed of about 3Mn/sec for the first few moves of a game, so your 6M speed sounds very fast to me.

What hardware did you use during the tournament?

I used an Intel E6700 core 2 duo processor which has a 2.67GHz clock speed, and running XP-64.

I have another game which I'll show you in a separate post.

-- Ed

[Ed Gilbert]

Hi Bert,

When I arrived at Amsterdam Saturday morning, I first visited Rein Halbersma at his home, because I could not check into my hotel until 1400 and I wanted to turn my computer on and make sure that it still worked after the airplane flight. If there were problems then maybe I could find a computer store and solve them before Sunday. Luckily everything was fine. Afterwards Rein decided to test kingsrow by playing it against Truus, only instead of letting Truus make all the moves, he influenced Truus in a few places to guide it along a certain line of attack that he thought might give Kingsrow trouble. The resulting game gave him quite a surprise, and I will show it to you here.

At the position just before move 29. kingsrow considered the position about even. At move 29, kingsrow expected that Truus was going to move 34-29. Instead Truus moved 31-26. Kingsrow immediately saw a search score of about +38 (0.38 man) because it sees it will be able to pitch 21-27 at move 30 and go down 2 pieces in order to get a king. At this point it is primariy heuristics driving the search, because obviously +38 is a heuristic score, not a database result. But the databases are affecting this because it knows about at least one of Truus' possible lines that leads to a loss. When Truus moved 38-32 at move 35, Kingsrow immediately saw 'database win', even though there are still 18 pieces left on the board. It quickly forced exchanges into an 8-piece endgame where black was 2 pieces down but in a database win ending.

[Event "Test game"]
[White "Truus + Rein"]
[Black "Kingsrow"]
[Result "0-1"]
1. 32-28 17-22 2. 28x17 12x21 3. 35-30 20-25 4. 40-35 15-20 5. 45-40
20-24 6. 33-29 24x33 7. 38x29 10-15 8. 42-38 21-26 9. 30-24 19x30 10.
35x24 14-19 11. 40-35 19x30 12. 35x24 5-10 13. 38-33 10-14 14. 24-20
15x24 15. 29x20 14-19 16. 20-15 16-21 17. 43-38 7-12 18. 49-43 1-7 19.
31-27 21x32 20. 37x28 18-22 21. 28x17 11x22 22. 36-31 26x37 23. 41x32
6-11 24. 46-41 11-17 25. 32-28 7-11 26. 41-37 11-16 27. 37-31 12-18
28. 38-32 16-21 29. 31-26 19-24 30. 43-38 21-27 31. 32x23 24-29 32.
28x17 29x49 33. 48-43 49-35 34. 33-28 9-14 35. 38-32 13-18 36. 23x12
3-9 37. 12x3 4-10 38. 15x13 35x49 39. 3x20 25x14


-- Ed

[BertTuyt]

When you wrote "Nevertheless, the parallel algorithm ( i go for YBWC) is not faster then the sequential one.", do you mean that your multi-thread search is not faster in nodes/sec than a single thread version? You also wrote that you are able to reach 6M nodes/sec. Does that mean your single thread search normally searches at this speed? Kingsrow hits a maximum speed of about 3Mn/sec for the first few moves of a game, so your 6M speed sounds very fast to me.


Ed, here is my answer.

* Every core operates at 1.5 MNodes/second (at 2.4 GHz)

* When i run all the same threads on all 4 cores (to test if my routines are multi-thread-safe) i reach a peak-speed of 4 * 1.5 MNodes/sec = 6M

* When i do parallel search the core work-balance is not optimal, and every core uses its own hash-table. Se despite running at a higher Nodes/sec. level (altough in average less then 6 M, as many cores are often idle), the time needed to reach the same ply is the same as the single-core sequential search-routine.

* So i will work on a better work-load balancing, and try to implement a efficient lock- (or lock-less) shared hash-table approach.

Impressive game against Truus.
Will replay it with Damage , and check to what extend i will find similar results.

Bert