Introducing Myrddin v0.0000001a

[AdminX]

Way to go John, Good work!

[Roman Hartmann]

Congratulation to your Engine!
It's quite some time ago since my engine played its first game but I remember well that I was really happy back then.

Just keep in mind that you soon will be hunting elo points and ways to improve your engine. Fun too, of course but by far not as satisfying as when your engine plays its first game

best regards
Roman

[Matthias Gemuh]

Congratulation to your Engine!
It's quite some time ago since my engine played its first game but I remember well that I was really happy back then.

Just keep in mind that you soon will be hunting elo points and ways to improve your engine. Fun too, of course but by far not as satisfying as when your engine plays its first game

best regards
Roman

Hi Roman,
does Roce 0.0380 support Chess960 ?
If not, where do I get the real thing.
Best,
Matthias.

[sje]

Keep in mind that perft movepath enumeration is good for program verification and for performance benchmarking of different versions of the same program, but it's not so good for comparing the relative performance of different programs.

Consider:

1) Some programs will use bulk terminal node counting while others will visit all nodes. A bulk terminal counter may run twenty times faster, but this is of little use in practical play.

2) Some programs use transposition tables in movepath enumeration and so obtain a huge speed-up.

3) Different programs vary wildly as to exactly what quantities are made available at each terminal node. For some programs, only the board and a few scalars needed for move generation are present. For other programs, several kilobytes of state information including bitboard attack matrices are available for all kinds of fun. It's the latter approach that's used by my programs.

----

In my C++ experimental program Tensor (the reorganized C++ part of Symbolic), each node has variables for:

1) Active and passive colors, castling availability, en passant target, half move counter, full move number, and the 64 element board vector;

2) Arrays for the counts of pieces by color[2] and by man[12];

3) Bitboards for all pieces merged, all sweeper pieces, pieces by color[2], pieces by man[12], attacks by color[2], attacks from each square[64], and attacks to each square[64];

4) A 64 bit hash for the board and another for the pawn subset;

5) A bitboard of all pinned pieces and another for all frozen pieces (absolute pins);

6) A flag for in-check status.

7) Pointers to saved data needed for repetition testing and move retraction.

Having all of the above makes fast, legal-move-only move generation easy. Profiling shows that less than three percent of CPU time is spent in the generator.

How fast does this run? About three million generate/execute/retract cycles per second on a single thread running on a 2.66 GHz Xeon.

Approximate speeds for other platforms (perft(7) = 3,195,901,860):

400 MHz PPC G4: 178707 Hz
1.13 GHz P3: 344981 Hz
3.0 GHz P4: 893244 Hz
2.0 GHz C2D: 2277870 Hz

[fern]

Congrats, John. No matter if the engine is weak by now, surely you got a thrill doing it and then looking it to play.
a hug
Fern

[Roman Hartmann]

Hi Mathias,
yes, Roce 0.038 supports (Schredder) chess960/frc. I'm not sure if it works with ChessGUI though as I have trouble with it on my (outdated) computer and wasn't able to test it. For some reason ChessGUI does not work here on my old Athlon (maybe because it lacks SSE2?). But I will give it a try on a more up to date computer this evening.

best regards
Roman

[Matthias Gemuh]

Hi Mathias,
yes, Roce 0.038 supports (Schredder) chess960/frc. I'm not sure if it works with ChessGUI though as I have trouble with it on my (outdated) computer and wasn't able to test it. For some reason ChessGUI does not work here on my old Athlon (maybe because it lacks SSE2?). But I will give it a try on a more up to date computer this evening.

best regards
Roman

I will test it under ChessGUI 0.137 and inform you if problems pop up.

Best,
Matthias.

[JVMerlino]

Hi John,
every engine is most valuable to the community if its weakest versions are also released. It should however support time controls x+y and x/y,
and protocol WB and/or UCI. Any other features is unimportant
But you know all this, as an old man in the scene.
Best,
Matthias.

Well, all of the very encouraging comments are giving me a little boost of energy, so things are progressing nicely so far.

I've now implemented two time controls, min/game and Fischer (which I think you're calling x+y). Moves/minutes (your x/y?) is next....once I figure out why promotions stopped working. :-p

jm

[trojanfoe]

Keep in mind that perft movepath enumeration is good for program verification and for performance benchmarking of different versions of the same program, but it's not so good for comparing the relative performance of different programs.

Consider:

1) Some programs will use bulk terminal node counting while others will visit all nodes. A bulk terminal counter may run twenty times faster, but this is of little use in practical play.

I've just re-written my move generator using a 'find_pinners' method and having a separate method for 'in-check' and 'not-in-check' move generation and found that my perft suite didn't find all the bugs. The best way to find move generator bugs I reckon is to get a really big game database, like MillionBase (http://www.top-5000.nl/dl.htm?file=dl/M ... 201.74.rar), and read every move. My move parser uses the move generator in order to disambiguate the SAN move and so errors in it will show up nicely, especially if you dump the position and FEN when an error is encountered. The problem is that MillionBase does contain several errors (odd characters in the move list or the wrong piece being moved) and as it's so large it takes a while to edit, but once you have cut out the rubbish you will find it invaluable. As the file was so large I built in read/write support for both compressed and uncompressed files which means I can at least store it in gzipped format.

The problem with the harder-to-find move generator bugs and perft is that they don't show up until ply 5 or 6 and so you are just guessing.

How fast does this run? About three million generate/execute/retract cycles per second on a single thread running on a 2.66 GHz Xeon.

Approximate speeds for other platforms (perft(7) = 3,195,901,860):

400 MHz PPC G4: 178707 Hz
1.13 GHz P3: 344981 Hz
3.0 GHz P4: 893244 Hz
2.0 GHz C2D: 2277870 Hz

My move generator went from 6.5Mnps to 14Mnps on a 3.0GHz E8400 under Vista x64 and to 16Mnps using the Intel C++ compiler 11.0 under Ubuntu 8.10 on the same machine. These are the official 'Hyatt' perft values - not using hash tables and making/unmaking every move.

Cheers,
Andy

[sje]

One technique I've used is to have the program synthesize a reproducible sequence of random games (each move is picked at random and the game continues until draw or mate). The games are scanned and at each position tests are run where essentially every interesting item is calculated in two different ways and the results compared. This can find all sorts of bugs that might go undetected with using real world games.

----

Recent movepath enumeration numbers (2.66 GHz Xeon, gnu g++):

Code: Select all

Depth: 0   Count: 1   Elapsed: 2e-06
500000 Hz   2e-06 seconds

Depth: 1   Count: 20   Elapsed: 8e-06
2.5e+06 Hz   4e-07 seconds

Depth: 2   Count: 400   Elapsed: 0.000102
3.92157e+06 Hz   2.55e-07 seconds

Depth: 3   Count: 8902   Elapsed: 0.002355
3.78004e+06 Hz   2.64547e-07 seconds

Depth: 4   Count: 197281   Elapsed: 0.052569
3.7528e+06 Hz   2.66468e-07 seconds

Depth: 5   Count: 4865609   Elapsed: 1.39188
3.4957e+06 Hz   2.86066e-07 seconds

Depth: 6   Count: 119060324   Elapsed: 35.8911
3.31727e+06 Hz   3.01453e-07 seconds

Depth: 7   Count: 3195901860   Elapsed: 993.677
3.21624e+06 Hz   3.10922e-07 seconds

The above is with a full bitboard database and other items at each post-execution terminal node. Bulk terminal counting runs about 16 times faster.