Monchester

[unserializable]

(Hint: the pgn viewer here has a selection menu above the board, three dots...)

Relevant hint! Did not expect Monchester at depth 5 to be so fond of English Opening. Considering its positional understanding, it won't be a match for the TRex monster there

Thanks Taimo. I did just two games now in CuteChess and also had no problems.

For CuteChess the known problem reported by Roland with encoding promotions for engines' moves will be fixed too. In fact, I discovered internal problem with black promotions that sometimes can cause illegal moves, also to be fixed. Underpromotions for both sides together with XBoard compatible mate score reporting were the only thing to my mind that kept Monchester from being 'feature complete', it encountered situation where e7e8n underpromotion was the best move and other promotions lose, so these damn underpromotions have practical relevance

[d]8/p2QPrk1/6p1/2q5/8/6P1/PPP2R1P/6K1 w - - 0 34

I even tried a default depth 5 version now at 40/180s and it lost only one of them on time (my slow hardware).

It behaves rather differently on different compilers too, largest difference I have personally seen on single codebase with identical compiler options -- on my aforementionened laptop --bench 6 is ~8200 kN/s compiled with clang 3.5 or 6 and ~4500 kN/s compiled with gcc 4, 5, 6, 7 or 8. I am rather certain that is happening because of microarchitectural alignment/caching effects, similar to e.g. discussed in Different performance of equal executables, but have not (yet) bothered to just blindly shuffle around object file linkage order to see whether results consistently change for better with gcc. Compiled code is similar enough to not account for such large difference.

But for slower Blitz it will be sufficient. I will upload both WIN compilations soon for testing

Thanks, that is very kind of you! 1.0 final code should be ready for release by the weekend too.

[Guenther]

(Hint: the pgn viewer here has a selection menu above the board, three dots...)

Relevant hint! Did not expect Monchester at depth 5 to be so fond of English Opening. Considering its positional understanding, it won't be a match for the TRex monster there :)

Well, the first 6 plies were from my testbook/pgn in this case. As I had seen Monchester pretended to support 'setboard' I wanted to check
also, if it will run smoothly with book moves fed and it did :)
Most testers nowadays use startpositions to get enough variety. In the past we often tested with exclusive own books.

...

I even tried a default depth 5 version now at 40/180s and it lost only one of them on time (my slow hardware).

It behaves rather differently on different compilers too, largest difference I have personally seen on single codebase with identical compiler options -- on my aforementionened laptop --bench 6 is ~8200 kN/s compiled with clang 3.5 or 6 and ~4500 kN/s compiled with gcc 4, 5, 6, 7 or 8. I am rather certain that is happening because of microarchitectural alignment/caching effects, similar to e.g. discussed in Different performance of equal executables, but have not (yet) bothered to just blindly shuffle around object file linkage order to see whether results consistently change for better with gcc. Compiled code is similar enough to not account for such large difference.

Good to know, I hadn't checked for this. After reading your message I compiled again with clang in Msys and indeed there is a notable difference.
Not as much as for your comparison with older compiler versions, but still enough to make me exchange the binaries I offered.
Actually it is around 3000-3100 kn/s vs. 3900-4000 kn/s in favour of clang on my old hardware for bench 6.
This was with gcc 10.2 vs. clang 10.

@other readers: I would like to see benchmarks on faster hardware after I have reuploaded the binaries again today.
(no matter if D5 or default they will behave the same)
Just start Monchester from cmd and type 'bench 6' and wait a little bit. It will show the result then.

Sure I will update my compilations also for the 1.00 release with your modifications.
BTW am I right that you are Estonian? I had added Monchester already to my XB/UCI chronology after your announcement.

[unserializable]

Most testers nowadays use startpositions to get enough variety. In the past we often tested with exclusive own books.

Thanks, that explains the personality change! I did some experiments with constant 5-ply search as well, but it did not seem to work well, lots of pointless queen movements were made and play felt unnatural. It was kind of expected, without quiescence extensions, odd search depths mean that last move considered will always be engine's own, whereas at even search depths last move is always opponents response -- effectively curing some weird movements made because of engine's imaginations of immediate material grabs

Good to know, I hadn't checked for this. After reading your message I compiled again with clang in Msys and indeed there is a notable difference.
Not as much as for your comparison with older compiler versions, but still enough to make me exchange the binaries I offered.
Actually it is around 3000-3100 kn/s vs. 3900-4000 kn/s in favour of clang on my old hardware for bench 6.
This was with gcc 10.2 vs. clang 10.

Good to know as well, more confirmation that gcc/clang differences are consistent so far (observed on my 2 laptops and 1 desktop).

Sure I will update my compilations also for the 1.00 release with your modifications.
BTW am I right that you are Estonian? I had added Monchester already to my XB/UCI chronology after your announcement.

Thank you, Guenther! I am indeed Estonian -- greetings to Regensburg, Germany, from the vicinity of Tartu, Estonia

This list is very impressive work, I should look for some new open-source sparring partners for Monchester from there.

EDIT: the Y-M-D FR for Monchester has year 2010 currently instead of 2020, otherwise all is correct.

[Guenther]

Thank you, Guenther! I am indeed Estonian -- greetings to Regensburg, Germany, from the vicinity of Tartu, Estonia :)

This list is very impressive work, I should look for some new open-source sparring partners for Monchester from there.

EDIT: the Y-M-D FR for Monchester has year 2010 currently instead of 2020, otherwise all is correct.

Oops corrected now, thanks Taimo. Greetings back to Tartu :)

Just a last note for now, the D5 version has a min depth 5, but the max depth is unchanged.
So this version is for a bit longer tc, like slow blitz or rapid etc.

[Guenther]

Thank you, Guenther! I am indeed Estonian -- greetings to Regensburg, Germany, from the vicinity of Tartu, Estonia :)

This list is very impressive work, I should look for some new open-source sparring partners for Monchester from there.

EDIT: the Y-M-D FR for Monchester has year 2010 currently instead of 2020, otherwise all is correct.

Oops corrected now, thanks Taimo. Greetings back to Tartu :)

Just a last note for now, the D5 version has a min depth 5, but the max depth is unchanged.
So this version is for a bit longer tc, like slow blitz or rapid etc.

It was too late to edit:
min depth should read as default depth above

[mvanthoor]

For CuteChess the known problem reported by Roland with encoding promotions for engines' moves will be fixed too. In fact, I discovered internal problem with black promotions that sometimes can cause illegal moves, also to be fixed. Underpromotions for both sides together with XBoard compatible mate score reporting were the only thing to my mind that kept Monchester from being 'feature complete', it encountered situation where e7e8n underpromotion was the best move and other promotions lose, so these damn underpromotions have practical relevance

[d]8/p2QPrk1/6p1/2q5/8/6P1/PPP2R1P/6K1 w - - 0 34

I think it's cool you've restarted work on your engine and chess programming in general. If you have any questions, there are many people here who are willing to help with either direct answers/explanations, or at least pointers in the right direction. My engine has greatly benefited from this assistance.

My engine Rustic agrees about your position with regard tot he promotion:

Code: Select all

info score cp 725 depth 1 seldepth 2 time 0 nodes 84 nps 0 pv e7e8q c5f2
info score cp 1100 depth 2 seldepth 3 time 0 nodes 199 nps 0 pv e7e8n g7g8 d7f7
info score cp 1100 depth 3 seldepth 5 time 0 nodes 1246 nps 0 pv e7e8n g7g8 d7f7
info score cp 1110 depth 4 seldepth 5 time 1 nodes 4664 nps 4664000 pv e7e8n g7h6 d7f7 c5d4
info score cp 1135 depth 5 seldepth 7 time 6 nodes 26290 nps 4381667 pv e7e8n g7h6 d7f7 c5d4 e8f6
info score cp 1135 depth 6 seldepth 7 time 25 nodes 106701 nps 4268040 pv e7e8n g7h7 d7f7 h7h6 e8f6 c5d4
info score cp 1145 depth 7 seldepth 8 time 134 nodes 605600 nps 4519403 pv e7e8n g7h7 d7f7 h7h6 e8f6 c5d4 c2c4
info score cp 1150 depth 8 seldepth 9 time 607 nodes 2820952 nps 4647367 pv e7e8n g7h6 d7h3 c5h5 h3h5 g6h5 f2f7 a7a5
info score cp 1170 depth 9 seldepth 10 time 4903 nodes 22595251 nps 4608454 pv e7e8n g7h7 d7f7 h7h6 e8f6 c5d4 c2c4 h6g5 f7d5
info score cp 1240 depth 10 seldepth 11 time 24805 nodes 121451615 nps 4896255 pv e7e8n g7h6 d7h3 c5h5 h3h5 g6h5 f2f7 a7a5 f7a7 h6g5 a7a5

(Note that Rustic is also an engine in an early development stage: it has no features yet, except for MVV-LVA sorting in the search, and material counting and PSQT's in the evaluation.)

[unserializable]

Just a last note for now, the D5 version has a min depth 5, but the max depth is unchanged.
So this version is for a bit longer tc, like slow blitz or rapid etc.

Hey Guenther, thanks for inspiring me to add another comment to the code That max depth #define is both a placeholder for later simply adding support for possible search extensions and initialization value for engine configuration setting that GUIs might want to adjust.

Code: Select all

/* /Effective/ ply depths are one greater than numbers here, 0-based. */
#define MONCHESTER_DEPTH_DEFAULT 3
/* Maximum effective ply depth for engine configuration initialization. This does
   currently not have any effect besides that when CECP 'sd' decreases maximum
   search depth to be lower than default, both default and maximum values search
   depth values are adjusted correspondingly, until the new game begins. */
#define MONCHESTER_DEPTH_MAX 7

So when default depth is set to 5, that search depth will be used all the time (setting MONCHESTER_DEPTH_MAX does not really atm cause searches to go deeper). However, maximum and effective depth can be decreased when XBoard maximum depth adjustment command 'sd' sets it lower than default, OR Monchester encounters situation where little heuristic on remaining game time causes it to decrease search depth. Which is unlikely to happen with default effective search depth 4, but depending on time control might happen with effective (default) search depth 5.

[unserializable]

I think it's cool you've restarted work on your engine and chess programming in general. If you have any questions, there are many people here who are willing to help with either direct answers/explanations, or at least pointers in the right direction. My engine has greatly benefited from this assistance.

...

(Note that Rustic is also an engine in an early development stage: it has no features yet, except for MVV-LVA sorting in the search, and material counting and PSQT's in the evaluation.)

Hey Marcel, congrats on the effective underpromotion and thanks for the kind words!

Wish you a persistence with Rustic -- writing chess engine from scratch is no simple feat and you seem to be doing excellently. Currently I can fairly say that my basic chess engine is much more basic than yours These alpha-beta & threading & PSQs & ... even MVV-LVA are powerful features & Monchester will probably fall between 800-1000 on CCRL 404, whereas Rustic in 1500-1700 range, as I understand from your latest posts on Rustic. Monchester recognizes repetitions, 50-move draws and insufficient material positions, counts material, gives piece placement bonus to knights only, values knights higher than bishops and considers one bishop to be worth ... 8 pawns -- I have tried to keep the logic and illogic for 1.0 release same as it would have been, had I managed to solve memory usage errors 18 years ago, while making code stable, faster, clearer and dependable. The constant search depth should give Monchester 1.0 also some reference quality, as it will play the same as it does today in 10 or 50 years from now.

The thing that I have found interesting is just how much hopeful struggle inexperienced human players have, beating or trying to beat blundering Monchester (as they do blunder too). I intend to check out Rustic one day, as I have neither compiled or written or really read any Rust code and would like to have basic familiarity with Rust toolchain and then try to beat your engine, before it becomes a monster. Hope you play a game or two with Monchester one day too

Dear readers! -- 1.0 release is coming along nicely, but so far I have not gotten any comments on Mac binaries -- I would really appreciate them, as neither myself nor my friend who compiled them was not exactly familiar with the process of distributing software for Mac. We discovered together that Mac does not really have quite the same static binary concept as in Linux, so we were forced to compile dynamic one -- confirmation or disconfirmation of Mac binary functionality would give some desired clarity

[mvanthoor]

Hey Marcel, congrats on the effective underpromotion and thanks for the kind words!

Wish you a persistence with Rustic -- writing chess engine from scratch is no simple feat and you seem to be doing excellently. Currently I can fairly say that my basic chess engine is much more basic than yours These alpha-beta & threading & PSQs & ... even MVV-LVA are powerful features & Monchester will probably fall between 800-1000 on CCRL 404, whereas Rustic in 1500-1700 range, as I understand from your latest posts on Rustic.

There are two ways to get the engine to keep receiving information while the search is running:

1. Peek into the keyboard buffer from the search (many programs in C use this).
2. Run the UCI/XBoard communication in a different thread, and send the information to the search thread.

Without some stunts and fancy flying using so-called "unsafe code", option 1 isn't possible in the Rust programming language. Therefore I use threads... and they're not your grandpa's threads. In Rust, threading is built right into the language and standard library, and once you 'get' the concept, it's very easy and logical.

You're right: I estimate Rustic to be somewhere around 1600-1650 on CCRL's Blitz list at this point. As said, it has no features but basic move ordering and PSQT's. It overperforms against some engines because it is very fast compared to many other 1500-1800 engines... but it sometimes also underperforms, because it's still stupid. It can sometimes tactically crush a CCRL 1800 engine like an egg because it outcalculates it by 3 ply in the middle game, and then be steamrollered by a CCRL 1500 engine because it doesn't know what king safety or a passed pawn is.

Alpha-Beta and MVV-LVA are basic features to get right in your engine to stand a chance of it ever having a decent search; and PSQT's aren't that hard either. Do you need assistance with this? I (and others) could easily explain this and/or show you some code.

Monchester recognizes repetitions, 50-move draws and insufficient material positions, counts material, gives piece placemet bonus to knights only, values knights higher than bishops and considers one bishop to be worth ... 8 pawns -- I have tried to keep the logic and illogic for 1.0 release same as it would have been, had I managed to solve memory usage errors 18 years ago, while making code stable, faster, clearer and dependable. The constant search depth should give Monchester 1.0 also some reference quality, as it will play the same as it does today in 10 or 50 years from now.

That is true; but you could implement a "go depth" (or the xboard equivalent), so your engine will then search to that depth and stop. In UCI, this is one of the standard commands an engine is expected to have. I assume it is in XBoard as well. (I still have to implement this interface.)

The thing that I have found interesting is just how much hopeful struggle inexperienced human players have, beating or trying to beat blundering Monchester (as they do blunder too). I intend to check out Rustic one day, as I have neither compiled or written or really read any Rust code and would like to have basic familiarity with Rust toolchain and then try to beat your engine, before it becomes a monster. Hope you play a game or two with Monchester one day too

One of the things I noticed is that even a basic chess engine is a tactical monster (compared to an average club player) if it can see 7-10 moves deep. It plays one innocuous move, which makes you think: "Why did it do that?" You can't find the reason, shrug your shoulders, and make your perfectly normal and natural move... and then the engine starts tearing you apart.

And you think: "But it doesn't work, because I'm now going to.... Aaargggh." And THEN you see, that this quiet move you couldn't figure out 10 moves ago, just HAPPENS to have put that bishop in JUST THAT position which blocks you from making precisely THAT move you just reached for, which makes the engine's combination work.

Dear readers! -- 1.0 release is coming along nicely, but so far I have not gotten any comments on Mac binaries -- I would really appreciate them, as neither myself nor my friend who compiled them was not exactly familiar with the process of distributing software for Mac. We discovered together that Mac does not really have quite the same static binary concept as in Linux, so we were forced to compile dynamic one -- confirmation or disconfirmation of Mac binary functionality would give some desired clarity

Sorry... can't help you there. I don't have a Mac, and I don't plan to get one. I might supply Mac binaries at some point, but they will be untested... or someone else has to compile Rustic for Mac.

[unserializable]

There are two ways to get the engine to keep receiving information while the search is running: ...

Third way is to just to have search that rans for short enough time that the command processing delay remains within bounds that interfaces accept as okay. For Monchester this means that analysis mode of XBoard is not supported, but otherwise things should be good and cross-platform, had no wish to do cross-platform threading or relatively low-level I/O code in C at this moment (even C11 threads are underspecified). Good to hear that Rust threading is nicely specified and supported in the standard library.

Alpha-Beta and MVV-LVA are basic features to get right in your engine to stand a chance of it ever having a decent search; and PSQT's aren't that hard either. Do you need assistance with this? I (and others) could easily explain this and/or show you some code.

Thanks for the help offer. This notion of 'basic' is rather advanced, starting with minimax should not anyhow hinder chances of 'decent search' -- though about MVV-LVA I have no knowledge, so will not challenge your assertion -- could you expand on that a little bit? About Alpha-Beta and PSQTs I feel that they should not be a problem to implement, but I think my first experiments after 1.0 will be:

• Game-wise: improving endgame play (without endgame tablebases).
• Tech-wise: cross-platform parallelism support

That is true; but you could implement a "go depth" (or the xboard equivalent), so your engine will then search to that depth and stop. In UCI, this is one of the standard commands an engine is expected to have. I assume it is in XBoard as well. (I still have to implement this interface.)

In XBoard there is "sd" command for search depth limit (command line parameter '-depth', '-searchDepth') , briefly also mentioned in this thread few posts ago. Not quite comfortable "fire and forget" as reference, as it requires some configuration, simple to forget or mess up during experiments.

One of the things I noticed is that even a basic chess engine is a tactical monster (compared to an average club player) if it can see 7-10 moves deep. It plays one innocuous move, which makes you think: "Why did it do that?" You can't find the reason, shrug your shoulders, and make your perfectly normal and natural move... and then the engine starts tearing you apart.

I am more thinking of scholastic chess than club players ATM. Really thought constant 4-ply search depth would be easier to beat for people who learned the moves and game long time ago or children just starting off.