Author: Vincent Diepeveen
Date: 14:12:12 07/20/99
Go up one level in this thread
On July 20, 1999 at 12:12:14, Dann Corbit wrote:
>I think it would be interesting to benchmark chess algorithms:
>0. Move generators -- all types
Cool idea. after 1.e4,e5 2.d4,d5 my program can generate
15.5M nodes a second at a PII450. Used compiler: msvc 6.0
My move format consists out of 2 integers.
I wonder what speed others get, i would be amazed if someone in C is
faster than this (perhaps with 8 bits generatorcode and by writing
out a generator for both white and black. my generator is general code,
works both for black and white).
>1. Alpha-Beta vs MTD(f)
See other postings of me what the disadvantages are for me and
what a worst case behaving of MTD was.
Something else is using an initial window different than
-infinite,+infinite; for example a quarter of a pawn
around the score of previous ply.
Although at average is is faster for me, in worst case situations
(fail low) it doesn't perform so well for me. A bigger window (1 pawn
window) doesn't give me a speedup.
Note that flip rate in DIEP is just 1%, which might explain why it
directly has a good variation.
>2. Bitboards vs 0x88
>3. etc.
4) what is the fliprate of your program
(chance that a node which is stored in hashtable as <= alfa
after searching it now becomes >= beta. So precondition is:
it has to be stored in hashtable and <= alfa. Postcondition:
giving a cutoff now). Measure at tournament level please;
so start with cleaned hashtable and let it run for some time,
like 3 minutes or something.
In DIEP: les than 1%
5) chance that first move gives cutoff
Very bad in DIEP: just 80% nowadays
Dan, we must find positions to measure those things at.
How many found next algorithms working for them
a) FHR (fail high reductions)
b) Probcut
c) history heuristic
d) countermove
e) singular extensions
I didn't find a single one of them working for DIEP.
Note that history heuristic did work when i just started DIEP.
>Prepare a large crosstable and do a large number of runs with as many
>implementations as possible and under as many different conditions as possible.
>
>Change the search time from very short searches (10 sec or less) up to half an
>hour to find the bit O(f(n)) properties of the algorithms.
>
>A systematic study might eliminate a lot of guesswork or even tell us *where*
>certain algorithms work better than others. For instance, we might use one
>algorithm at a certain time control and a different algorithm at a longer time
>control and yet another at correspondence chess time controls.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.