All results in <a href=http://toernooibase.kndb.nl/opvraag/sta ... =1169&jr=9 target=blank>Toernooibase</a>
Games can also be inserted into Toernooibase (or send them in .pdn to me).
Open Dutch Championship Computerdraughts
-
Piet Bouma
- Posts: 3574
- Joined: Sun Nov 02, 2003 13:05
- Location: Harlingen
Re: Champion
Added: five games of champion BoomstraDam plus photo's!Piet Bouma wrote:All results in <a href=http://toernooibase.kndb.nl/opvraag/sta ... =1169&jr=9 target=blank>Toernooibase</a>
Games can also be inserted into Toernooibase (or send them in .pdn to me).
-
Ed Gilbert
- Posts: 860
- Joined: Sat Apr 28, 2007 14:53
- Real name: Ed Gilbert
- Location: Morristown, NJ USA
- Contact:
Feike, congratulations on your fine performance in winning the tournament. I think you must have made some good improvements to BoomstraDam in the last year, based on this tournament and also your post about recent games against Dam2.2. I wonder what kinds of changes you have been making to cause the increase in playing strength? Search changes, new evaluation terms, opening book? Something else? Also, did you have any particularly interesting games from the weekend that you can share here? It's nice to see some new programs showing up as well as improvements to some like yours that have been playing for a while.
-- Ed
-- Ed
Feike. congratulations.
Interesting to see these comments from the 3 programs not present Kingsrow, Damy and Damage. [img]images/smilies/icon_smile.gif[/img]
Think we are all afraid to play.
I have to agree with Ed, i am very interested what improvements you made towards BoomstraDam. Next to that I like all details like hardware played on, databases used ( 6man or 7 man), hashtables, search, book, nr nodes/sec etc...
Although i was not there this time, im sure I will show up during 2009.
Bert
Interesting to see these comments from the 3 programs not present Kingsrow, Damy and Damage. [img]images/smilies/icon_smile.gif[/img]
Think we are all afraid to play.
I have to agree with Ed, i am very interested what improvements you made towards BoomstraDam. Next to that I like all details like hardware played on, databases used ( 6man or 7 man), hashtables, search, book, nr nodes/sec etc...
Although i was not there this time, im sure I will show up during 2009.
Bert
-
FeikeBoomstra
- Posts: 306
- Joined: Mon Dec 19, 2005 16:48
- Location: Emmen
First of all, I bought a new computer. Seeing my perft score at 200 while the others were in the 30 region. So I bought a Q9450. The next problem was parallelism.
My third attempt was successful. Ed suggestion of glaurung was my break through. Finally I had an implementation that made sense.
No threads: around 1050 kNodes/sec. With threads it goed down to 880. (this is with locks on the hash). With 4 cores, around 3000 kNodes/sec. Not so much, but eval takes about 40% of the time. And as depth go exponential and better evaluation goes lineair, I take that for granted.
It took me very long to get the parallel implementation stable. For a long time I had, say one out of hundred, a different move from 4 threads and 1 thread. Finally I found the problem, I halted the parallel threads incorrectly.
It took me a very long time to really understand the glaurung implementation.
Other things I did:
I ignored captures in my depth counting. As such, not a bad idea, but the consequences was that the time steps are much bigger. When I saw the relation between "feed" and average depth from Ed, I realized that the timing is much more easy in his case, so I changed my depth calculation.
Due to the discussions her about the move generation I made an update and generated the moves without the index. But I can't beat Bert. No bulk: around 26 sec.
I lost my first game, a very simple 1 to 2 combination that I simply forgot to implement. When I was busy with it, I realized that on the edge you need only two man's in a row, but later on, I forgot to implement it.
I replaced my (don't know the correct word in English) voorpost procedure. The old one, I didn't understand myself anymore, it was so complex, so many macro's. So I rewrote the whole thing in python. I mean, I made a c-code generator in python. I was a little bit too aggressive, so I improved my calculations for numbers of attack, numbers of defense, time of attack, time of defense and the possibility of simply exchange the "voorpost". And now, as long as I understand the code generator, I just have to check whether the output looks ok.
I made a small routine to prevent pieces exchange just to gain a very small amount. To be honest, I didn't see the effect, but I didn't investigate it yet.
I implemented a "panic stop" in case the next depth takes too much time.
I already had a granularity in my eval function. In the early days, it didn't matter a lot, but as things a becoming more stable, the number of nodes evaluated decreases substantialiy (forgot the number) if I increase the granularity. My current number is 0.02 (man is 1.0)
Next thing I like to share is the number of "move changes" during the "depthening", what I mean is the following: how many changes you see in the preferred move when going to the next depth. What I see now is that the move is rather stable, the evaluation isn't.
(in general it goes down, if it goes up I am going to win.)
Feel free to ask questions.
Feike.
My third attempt was successful. Ed suggestion of glaurung was my break through. Finally I had an implementation that made sense.
No threads: around 1050 kNodes/sec. With threads it goed down to 880. (this is with locks on the hash). With 4 cores, around 3000 kNodes/sec. Not so much, but eval takes about 40% of the time. And as depth go exponential and better evaluation goes lineair, I take that for granted.
It took me very long to get the parallel implementation stable. For a long time I had, say one out of hundred, a different move from 4 threads and 1 thread. Finally I found the problem, I halted the parallel threads incorrectly.
It took me a very long time to really understand the glaurung implementation.
Other things I did:
I ignored captures in my depth counting. As such, not a bad idea, but the consequences was that the time steps are much bigger. When I saw the relation between "feed" and average depth from Ed, I realized that the timing is much more easy in his case, so I changed my depth calculation.
Due to the discussions her about the move generation I made an update and generated the moves without the index. But I can't beat Bert. No bulk: around 26 sec.
I lost my first game, a very simple 1 to 2 combination that I simply forgot to implement. When I was busy with it, I realized that on the edge you need only two man's in a row, but later on, I forgot to implement it.
I replaced my (don't know the correct word in English) voorpost procedure. The old one, I didn't understand myself anymore, it was so complex, so many macro's. So I rewrote the whole thing in python. I mean, I made a c-code generator in python. I was a little bit too aggressive, so I improved my calculations for numbers of attack, numbers of defense, time of attack, time of defense and the possibility of simply exchange the "voorpost". And now, as long as I understand the code generator, I just have to check whether the output looks ok.
I made a small routine to prevent pieces exchange just to gain a very small amount. To be honest, I didn't see the effect, but I didn't investigate it yet.
I implemented a "panic stop" in case the next depth takes too much time.
I already had a granularity in my eval function. In the early days, it didn't matter a lot, but as things a becoming more stable, the number of nodes evaluated decreases substantialiy (forgot the number) if I increase the granularity. My current number is 0.02 (man is 1.0)
Next thing I like to share is the number of "move changes" during the "depthening", what I mean is the following: how many changes you see in the preferred move when going to the next depth. What I see now is that the move is rather stable, the evaluation isn't.
(in general it goes down, if it goes up I am going to win.)
Feel free to ask questions.
Feike.
-
Ed Gilbert
- Posts: 860
- Joined: Sat Apr 28, 2007 14:53
- Real name: Ed Gilbert
- Location: Morristown, NJ USA
- Contact:
Hi Feike,
Thanks for the nice summary of all your improvements.
Your 3x improvement in going from one search thread to four is the same as what I observe.
About the voorpost squares, I also re-wrote my eval for these several times, and this was long before I knew that these squares had a name I learned about these things by watching kingsrow lose to other programs.
-- Ed
Thanks for the nice summary of all your improvements.
Your 15% drop in kN/s going from single-threaded to multi-threaded enabled but one thread is a lot. In my case this is a very small drop, about 2% - 3%. It was small enough that I did not feel it necessary to keep separate compile targets for single vs. multi, I just have one version that is always multi-threaded enabled. Do you still have locks on the hashtable? That would explain the drop. I don't think you need any locks there. If I get a bestmove from the hashtable I always check that it is a legal move in the current position, so it should not be a big problem if once in a while the hashtable entry is inconsistent. It is better to have the 15% higher speed and live with the possibility of inconsistent hashtable entries.No threads: around 1050 kNodes/sec. With threads it goed down to 880. (this is with locks on the hash). With 4 cores, around 3000 kNodes/sec. Not so much, but eval takes about 40% of the time. And as depth go exponential and better evaluation goes lineair, I take that for granted
Your 3x improvement in going from one search thread to four is the same as what I observe.
About the voorpost squares, I also re-wrote my eval for these several times, and this was long before I knew that these squares had a name I learned about these things by watching kingsrow lose to other programs.
IIRC we talked about this at dinner after last year's tournament. I also use .02 for granularity. I always wondered how much stronger Dam2.2 would be if Harm fixed this -- its granularity is something like 3E-7.I already had a granularity in my eval function. In the early days, it didn't matter a lot, but as things a becoming more stable, the number of nodes evaluated decreases substantialiy (forgot the number) if I increase the granularity. My current number is 0.02 (man is 1.0)
-- Ed
Hi Feike, Ed
In the past I had a 2-thread version of Damy based on an alpha-beta procedure.
Since then I have changed my procedure to a MTD-f-best procedure but with only one thread. I am now working on a new procedure due to the following reason :
The MTD-f-best procedure is very efficient if it is Damy to move but is not satisfactory when the move is to the opponent. As a consequence I study a new procedure dedicated to the situation where the move is to the opponent. It will be some mixture of alpha-beta and MTD-f procedure. Depending of the result of my tests it might happen that I will use this new procedure if it is also Damy to move.
At the same time I am writing a multithread version, consistent with my new procedure. It will not be the strict "YBW" procedure but a variation in order to avoid the "waiting" state and in order to take into account some particularies of my procedure.
Concerning the hashtable, in order to avoid locks, I only added a cheksum in each record. That way I can be confident with the bestmove I get from the hash table and I am able to avoid a call to the move generator in case of cutoff.
Gérard
In the past I had a 2-thread version of Damy based on an alpha-beta procedure.
Since then I have changed my procedure to a MTD-f-best procedure but with only one thread. I am now working on a new procedure due to the following reason :
The MTD-f-best procedure is very efficient if it is Damy to move but is not satisfactory when the move is to the opponent. As a consequence I study a new procedure dedicated to the situation where the move is to the opponent. It will be some mixture of alpha-beta and MTD-f procedure. Depending of the result of my tests it might happen that I will use this new procedure if it is also Damy to move.
At the same time I am writing a multithread version, consistent with my new procedure. It will not be the strict "YBW" procedure but a variation in order to avoid the "waiting" state and in order to take into account some particularies of my procedure.
Concerning the hashtable, in order to avoid locks, I only added a cheksum in each record. That way I can be confident with the bestmove I get from the hash table and I am able to avoid a call to the move generator in case of cutoff.
Gérard
Feike,
Ed/Gerard, as I will start (again) on the parallel search algorithms during Xmas, I have the next question.
As I understood, in the case of Glaurung the threads are activated in case a valid splitpoint is available. This is done in a Master-Slave relationship.
My question what is the best approach:
- A Master-Slave where the search-thread invites idle treads to join.
- Or a approach where the idle threads themselves are looking for work, and then take the initiative.
Bert
Ed/Gerard, as I will start (again) on the parallel search algorithms during Xmas, I have the next question.
As I understood, in the case of Glaurung the threads are activated in case a valid splitpoint is available. This is done in a Master-Slave relationship.
My question what is the best approach:
- A Master-Slave where the search-thread invites idle treads to join.
- Or a approach where the idle threads themselves are looking for work, and then take the initiative.
Bert
-
Ed Gilbert
- Posts: 860
- Joined: Sat Apr 28, 2007 14:53
- Real name: Ed Gilbert
- Location: Morristown, NJ USA
- Contact:
Re: Date change
Hi Gerard,
-- Ed
It looks like I will be in Paris that weekend. It might be possible for me to bring a laptop and attend the tournament. What is the best way to get from Paris to the tournament site (in Hamel?)? Do you know if anyone is driving from the Paris area that might be able to give me a ride?TAILLE wrote:My next competion will be the French Open computer tournament the 17th May 2009 in north of France.
Gérard
-- Ed
Re: Date change
Hi Ed.
I am living 60 km west of Paris and I will be very pleased to help you as far as possible. No problem in particular to assure your transport from Paris (airport or hotel) to Hamel. In addition, I will be also very pleased to invite you at home before or after the tournament. Do not book a hotel if it is not necessary.
For your information Hamel is 220km from my home. It is possible to make the trip to Hamel on Saturday or early in the morning on Sunday 17th May.
In any case I am looking forward to seeing you in Hamel,
Gérard
Very good news Ed. Everybody will be very happy to see you again in a tournament organised in Europe.Ed Gilbert wrote:Hi Gerard,It looks like I will be in Paris that weekend. It might be possible for me to bring a laptop and attend the tournament. What is the best way to get from Paris to the tournament site (in Hamel?)? Do you know if anyone is driving from the Paris area that might be able to give me a ride?TAILLE wrote:My next competion will be the French Open computer tournament the 17th May 2009 in north of France.
Gérard
-- Ed
I am living 60 km west of Paris and I will be very pleased to help you as far as possible. No problem in particular to assure your transport from Paris (airport or hotel) to Hamel. In addition, I will be also very pleased to invite you at home before or after the tournament. Do not book a hotel if it is not necessary.
For your information Hamel is 220km from my home. It is possible to make the trip to Hamel on Saturday or early in the morning on Sunday 17th May.
In any case I am looking forward to seeing you in Hamel,
Gérard
-
Ed Gilbert
- Posts: 860
- Joined: Sat Apr 28, 2007 14:53
- Real name: Ed Gilbert
- Location: Morristown, NJ USA
- Contact:
Hi Gerard,
Thank you for offering your hospitality! I will be in vacationing with my wife and three daughters in France and Italy in May, and that is why I will be in Paris on the weekend of the 17th. It would be very nice if we could ride together to the tournament. The women have no interest in draughts and will stay in Paris sightseeing on that Sunday. We can discuss details later when as we get closer to that date and our travel plans are confirmed.
-- Ed
Thank you for offering your hospitality! I will be in vacationing with my wife and three daughters in France and Italy in May, and that is why I will be in Paris on the weekend of the 17th. It would be very nice if we could ride together to the tournament. The women have no interest in draughts and will stay in Paris sightseeing on that Sunday. We can discuss details later when as we get closer to that date and our travel plans are confirmed.
-- Ed
Ed,Gerard,
Interesting as I also want to join this tournament.
Will be busy [img]images/smilies/icon_smile.gif[/img]
Bert
Interesting as I also want to join this tournament.
Will be busy [img]images/smilies/icon_smile.gif[/img]
Bert
