Greetings and new Eubos chess engine

[c_j_bolt]

Hi All,

My name is Chris and I have joined the forum to offer my chess engine, Eubos, for CCRL testing.

Eubos was developed by myself from scratch over the course of the last four years. It is implemented in Java and available as an executable JAR binary. Over the last year it has had a lot of development and testing against a few other engines on the Lichess website. It is very much an ongoing concern, there is quite a lot of functionality I would still like to implement (draw detection is pretty rudimentary, for instance, and there is no formal king safety component in the evaluation function!).

However I think I have it debugged sufficiently that I can offer it here for testing. To that end I have added the binary for version 1.0.2 on github:

https://github.com/cjbolt/EubosChess/tr ... sChess/bin
https://github.com/cjbolt/EubosChess/re ... tag/V1.0.2

I believe it meets the requirements for testing. There is no book and the hash table size can be configured. Because it is implemented rather crudely in Java, the speed of the engine is not impressive. I generally find it runs at about 50-70K nps in typical opening and middlegame positions.

Features

• Quiescense search extension
• Zobrist transposition hashing
• Draw by 3-fold reptition detection
• Basic evaluation of piece mobility
• Basic evaluation of pawn structure

I look forward with interest to seeing where Eubos fits into the CCRL tables. I am already considering a C implementation

By the way, I have pretty much comprehensively used the excellent book "How Computers Play Chess", by Newborn and Levy, to develop Eubos. Most of the algorithms are from the outlines detailed in there. Thanks to those authors, I love that book!

[Gabor Szots]

Hi Chris,

Welcome to your engine! I'm glad to read you have consistently developed it and you also have plans for the future.

A little estimate of strength would also be welcomed so that we can select appropriate opponents. And I have to admit that usually I do not test engines under about 1200 so if your engine is below that threshold then most probably I'd skip it for now. On the other hand, other testers may not be so picky.

Gabor

EDIT: I have downloaded and installed Eubos under Arena. Playing a game I observed that the occupied memory was constantly growing, by the end of the game it reached 1 GB (I allocated 256 MB).

[c_j_bolt]

Hi Gabor,

Regarding the memory issue, I have found it quite difficult to control the memory used by the Java Virtual Machine. This is because of the way that the JVM handles garbage collection. Basically, when an object no longer has any references to it, it can be garbage collected. However, the design of the JVM is such that the garbage collection is not performed as soon as the object has a zero reference count, rather it occurs when the free memory in the heap starts to run out. I imagine your JVM, when not configured otherwise, has a large default heap. If you were to use a profiler, I imagine you would see that periodically the used heap would decrease as garbage collection runs.

To constrain Eubos to use no more than say 256 MBytes (for all its internal data - the hash table is just part of the RAM data structures) you need to tell the JVM to use less heap space. This can be done using additional commands in the batch file used by Arena to start the engine. For example, try:

java -Xms256m -Xmx256m -jar .\Eubos.jar

To constrain the heap such that you can be sure Eubos doesn't exceed its configured hash table size. Note: I have tested this extensively, it's just one has rather less control of memory in Java than in a language like C!

Please can you give that a try. Unfortunately this hot swapping of the heap causes performance slow downs, but Eubos will just have to bear that for being implemented in Java!

Regarding its ELO, I really don't have much of an idea. Running on my laptop it can beat "Chess Children" on the Lichess site, which I believe is one of the Engines already on the CCRL (edit: it is aka Safrad 2.2.40.360). It's blitz rating is 1900ish, but that isn't based on common hardware - I know a lot of the engines it plays against are actually faster but run on slower hardware. For example it is about 50% win rate against Overhead on Lichess, but on the same machine in Arena, Overhead is several orders of magnitude faster and wins easily!

You can see information about it's rating history here:

https://lichess.org/@/eubos

[c_j_bolt]

Regarding an ELO for Eubos, I created a couple of tournaments in Arena to try to get a better idea. Because I normally played engine vs engine via Lichess, and this isn't a level playing field, I didn't realise quite how weak it is!

My estimate of its ELO is somewhere between 1000 and 1200 points.

Engine Score Dr En Eu Gr S-B 1: Dragontooth-0.2-bahamut-WINDOWS-x64-64bit 6.0/6 ·· 11 11 11 12.00 2: Enxadrista 4.0/6 00 ·· 11 11 4.00 3: Eubos 2.0/6 00 00 ·· 11 0.00 4: GrayMatterSVN1604 0.0/6 00 00 00 ·· 0.00 Engine Score Eu NS Sa S-B 1: Eubos 3.5/4 ·· =1 11 3.75 2: NSVChess v0.14 2.5/4 =0 ·· 11 1.75 3: Safrad 0.0/4 00 00 ·· 0.00

[Gabor Szots]

Regarding an ELO for Eubos, I created a couple of tournaments in Arena to try to get a better idea. Because I normally played engine vs engine via Lichess, and this isn't a level playing field, I didn't realise quite how weak it is!

My estimate of its ELO is somewhere between 1000 and 1200 points.

Engine Score Dr En Eu Gr S-B 1: Dragontooth-0.2-bahamut-WINDOWS-x64-64bit 6.0/6 ·· 11 11 11 12.00 2: Enxadrista 4.0/6 00 ·· 11 11 4.00 3: Eubos 2.0/6 00 00 ·· 11 0.00 4: GrayMatterSVN1604 0.0/6 00 00 00 ·· 0.00 Engine Score Eu NS Sa S-B 1: Eubos 3.5/4 ·· =1 11 3.75 2: NSVChess v0.14 2.5/4 =0 ·· 11 1.75 3: Safrad 0.0/4 00 00 ·· 0.00

Thanks. I myself played a game against it and it was a rook down after a couple of moves so I feared it was not the strongest.

Nevertheless I am looking forward to its progress. Good luck!

[c_j_bolt]

Please use Eubos v1.0.2 for testing. This can be found at

https://github.com/cjbolt/EubosChess/re ... tag/V1.0.2

I have reworked the hash table allocation so that it cannot exceed 40% of the JVM's available heap. I found this helped a performance bottle-neck that could occur when the heap was configured at the same size as the configured hash table allowance.

I have also disabled logging (this should have been done prior to the original v1.0.1 Eubos release

[Gabor Szots]

Please use Eubos v1.0.2 for testing. This can be found at

https://github.com/cjbolt/EubosChess/re ... tag/V1.0.2

I have reworked the hash table allocation so that it cannot exceed 40% of the JVM's available heap. I found this helped a performance bottle-neck that could occur when the heap was configured at the same size as the configured hash table allowance.

I have also disabled logging (this should have been done prior to the original v1.0.1 Eubos release

OK, thanks.

A remark: on your page you say it is for CCRL testing. I would not exclude other groups and individuals from testing...

And, I have run it against Cerulean and it won 6-4, which encourages me to include it in my testing queue. Stay tuned.

[c_j_bolt]

Great, I'm glad you think testing Eubos could be worthwhile. I also tried to benchmark Eubos 1.0.2 against a selection of other engines in the 1200 to 1300 bracket. I did this with the strict limit of a 256M Java heap (though I don't think it is actually fair - the limit should just be for the hash table size, and this leaves no room for regular ram variables etc), as I wanted to see how Eubos could perform even under this most stringent criteria. Eubos came second, the top engine has a rating around 1350 in blitz. I'm pleased with the result, it certainly gives me something to build upon

Engine Score Vi Eu Ki Dr Ce En Jo Sa NS S-B 1: VirutorChessUci_1.1.2 28.5/32 ···· 1111 0=11 11=1 =111 1111 =111 1=11 1111 407.75 2: Eubos 20.5/32 0000 ···· 1=1= 1001 =101 1111 1101 1010 1111 274.00 3: KillerQueen_20b3 18.5/32 1=00 0=0= ···· 1100 01=1 1101 0111 11=0 0111 262.00 4: Dragontooth-0.2-bahamut-WINDOWS-x64-64bit 18.5/32 00=0 0110 0011 ···· 01=0 01=0 1101 1111 1111 230.50 5: Ceruleanjs 17.0/32 =000 =010 10=0 10=1 ···· 0=11 10=1 111= =1== 229.00 6: Enxadrista 16.5/32 0000 0000 0010 10=1 1=00 ···· 1111 1111 1=11 184.75 7: Joana_DC 10.0/32 =000 0010 1000 0010 01=0 0000 ···· 1010 =1=1 133.25 8: Safrad 7.5/32 0=00 0101 00=1 0000 000= 0000 0101 ···· 1000 118.50 9: NSVChess v0.14 7.0/32 0000 0000 1000 0000 =0== 0=00 =0=0 0111 ···· 84.75 144 games played / Tournament finished Level: Blitz 3/2 Hardware: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz with 7.8 GB Memory

I would now revise my estimate of Eubos's strength to be circa 1320 (still very weak, I know!)

[Gabor Szots]

OK, I've started a tourney. Had to include -Xm1024 in the command line lest it goes above 1 GB. And I noticed it used about 30-35 % CPU when it should be 25 % (4-core machine).
And it would be good if it displayed its PV.

[c_j_bolt]

Had to include -Xm1024 in the command line lest it goes above 1 GB. And I noticed it used about 30-35 % CPU when it should be 25 % (4-core machine).
And it would be good if it displayed its PV.

Hmm, something funny is going on if you can't see the PV? It is reported back to Arena on every back up to the root node (that changes the best move OR is the start of a new depth iteration). Eubos should provide all the UCI spec'd info messages, including hash utilisation. You will see this ticking up to 100% and then resetting down to circa 40-70% as it culls Transpositions from the hash table based on their access count.

I see all this in Arena. You should also see it reporting the speed in nps at least every second. Are you using 2/1 blitz time control?

Be sure to use -Xms1024m -Xmx1024m to constrain the heap (or -Xms1g -Xmx1g, which is equivalant). It may be using some MIPS in the thread that handles the UCI protocol and the info message reporting, but that shouldn't be 5-10% of total (though garbage collection runs in the JVM in another thread, so that could certainly explain some of the 5-10%). Can you please double check the command line is correct, thanks.

[Gabor Szots]

It is indeed funny (or not). My command line is OK. If I tell Eubos to analyze the start position it displays everything you mention - but only after a couple of seconds, at depth 7. However, when playing a game (at 2+1), only e.g. 'Best move: Rd1-c1' is displayed (when the move is played, not sooner).
It seems it is due to some delay in communication.

[c_j_bolt]

If I tell Eubos to analyze the start position it displays everything you mention - but only after a couple of seconds, at depth 7. However, when playing a game (at 2+1), only e.g. 'Best move: Rd1-c1' is displayed (when the move is played, not sooner).
It seems it is due to some delay in communication.

Ok, it sounds like there is a latency in launching the SearchMetricsReporter thread, or getting it running properly. I'm not very clued up when it comes to all the threading APIs. I suspect I am somehow creating a deadlock between the SearchMetricsReporter (uci info messages) and the PlySearcher (alpha beta recursive thread that generates the best move). This then causes nothing to be sent for the first few iterations of the iterative deepening ply search. When analysed from start, there is time enough for this deadlock to unblock, but in the 2+1 games, it never gets cleared before the move timer expires, resulting in no info messages.

Sorry for the inconvenience, but it is good information - I will look into the threading a bit more!

[Gabor Szots]

I have been watching a couple of games and it seems that the PV and other information is displayed only from depth 8.

And a strange thing happened. After 120 games Eubos did not move any more, it lost all subsequent games on time. Even quitting Arena and restarting it did not help. I had to delete the engine and reinstall it again. Maybe important, for this second installation I used Java 8, for the first one I used Java 11 (yes, I have two Java installations on my PC, some engines do not work with Java .
Now everything seem fine, the question is how long. I don't think I will be able to answer that question because I'm going to turn off my PC for the night.

[c_j_bolt]

After 120 games Eubos did not move any more, it lost all subsequent games on time. Even quitting Arena and restarting it did not help. I had to delete the engine and reinstall it again. Maybe important, for this second installation I used Java 8, for the first one I used Java 11

Hi Gabor, I have been trying to understand what could have gone wrong here. I haven't got any explanation. I have always used Java 8, though seeing as it is meant to be fully backwards compatible, using Java 11 shouldn't matter - as far as I can tell. I have probably never got as far as running Eubos for 120 games in one session. Do you use Arena for your tournaments? If so, do you restart the engine between games (Tournament > Start/Quit tab > Restart engines after each game)?

I am going to try and install Java 11 and test.

I also need to get to the bottom of the info message defect you have reported, which, having reviewed the code briefly, I am quite confused by. I don't suppose you could provide a snippet of the Debug log of the Engine uci comms (again, if using Arena). That way I can double check what Eubos is sending with respect to the code?

[Gabor Szots]

Hi Gabor, I have been trying to understand what could have gone wrong here. I haven't got any explanation. I have always used Java 8, though seeing as it is meant to be fully backwards compatible, using Java 11 shouldn't matter - as far as I can tell. I have probably never got as far as running Eubos for 120 games in one session. Do you use Arena for your tournaments? If so, do you restart the engine between games (Tournament > Start/Quit tab > Restart engines after each game)?

I am going to try and install Java 11 and test.

I also need to get to the bottom of the info message defect you have reported, which, having reviewed the code briefly, I am quite confused by. I don't suppose you could provide a snippet of the Debug log of the Engine uci comms (again, if using Arena). That way I can double check what Eubos is sending with respect to the code?

Hi Chris,

Maybe Java 11 leaves something in memory that causes trouble after a time. I switched on my machine about 6 hours ago and the tournament has been running since then (using Java8). About 80 games have been played today. I attach a random Arena debug for you which I have just copied from the running tournament.

Also, I have noticed that Eubos does display its PV beginning with depth 8 but nps and hash information is still missing.

[c_j_bolt]

Thanks for that log, it is very interesting. Something about your setup with Arena is quite different to mine.

If I'm not wrong, Eubos is sending the info messages, but they are not being displayed in Arena. I think in the log snippet below, PID6204 is Eubos I recognise the format of the uci commands (specifically the ordering and partial search depths). It has sent its PVs to depth 7 seldepth 17. this tallies with you saying that you see them after depth 8 in the GUI:


2020-02-01 12:36:51,802*1*Child Process Prio Adj: PID 6204 conhost.exe
2020-02-01 12:36:51,802*1*Start calc, move no: 79
2020-02-01 12:36:51,818-->1:position startpos moves g1f3 b7b6 e2e4 c8b7 d1e2 e7e6 g2g3 g8f6 b1c3 b7a6 d2d3 d7d5 e4e5 f6g8 c1g5 g8e7 b2b4 h7h6 g5d2 d5d4 c3e4 b8c6 c2c3 e7d5 b4b5 d4c3 b5a6 c3d2 e1d2 f8b4 d2c1 b4a3 c1c2 f7f5 e5f6 g7f6 c2b1 f6f5 e2c2 d8d7 e4d2 e6e5 c2b3 a3b4 f1h3 c6d4 f3d4 b4d2 h3f5 d7f7 b3b5 e8e7 b5d7 e7f6 d7f7 f6f7 f5e6 f7f6 e6d5 a8d8 d4f3 d2c3 d5c4 h8h7 a2a4 c3a1 b1a1 c7c6 a1b1 h7d7 h2h4 f6f5 h1e1 d8e8 h4h5 f5f6 d3d4 e5e4 c4b3
2020-02-01 12:36:51,818-->1:go wtime 52133 btime 60218 winc 1000 binc 1000
2020-02-01 12:36:51,833<--1:info depth 1 seldepth 0 score cp 158 pv e4f3 time 0
2020-02-01 12:36:51,849<--1:info depth 2 seldepth 5 score cp -374 pv e4f3 e1e8 time 0
2020-02-01 12:36:51,865<--1:info depth 2 seldepth 5 score cp -186 pv b6b5 a4b5 time 0
2020-02-01 12:36:51,865<--1:info depth 2 seldepth 5 score cp -101 pv c6c5 d4c5 time 0
2020-02-01 12:36:51,880<--1:info depth 3 seldepth 0 score cp -101 pv c6c5 d4c5 b6c5 time 0
2020-02-01 12:36:51,896<--1:info depth 4 seldepth 0 score cp -101 pv c6c5 d4c5 b6c5 e1e3 time 0
2020-02-01 12:36:51,912<--1:info depth 5 seldepth 0 score cp -101 pv c6c5 d4c5 b6c5 e1e3 d7g7 time 15
2020-02-01 12:36:52,349<--1:info depth 6 seldepth 13 score cp -176 pv c6c5 d4d5 f6f5 b3c4 d7g7 d5d6 time 530
2020-02-01 12:36:53,583<--1:info depth 7 seldepth 15 score cp -146 pv c6c5 b3c2 c5d4 e1e4 e8e4 c2e4 d4d3 time 1827
2020-02-01 12:36:57,224<--1:info depth 7 seldepth 17 score cp -128 pv d7d8 f3e5 d8d4 e5c6 d4d2 e1f1 d2d5 time 5561
2020-02-01 12:36:57,239<--1:info currmove d7c7 currmovenumber 12
...
2020-02-01 12:36:57,395<--1:info currmove e8e6 currmovenumber 19
2020-02-01 12:36:57,395<--1:info hashfull 685 nps 83863 time 6077 nodes 509639
2020-02-01 12:36:57,411<--1:info currmove e8e5 currmovenumber 20
...
2020-02-01 12:36:57,520<--1:info hashfull 687 nps 87129 time 6077 nodes 529488
2020-02-01 12:36:57,536<--1:info hashfull 687 nps 85802 time 6171 nodes 529488
2020-02-01 12:36:57,552<--1:bestmove d7d8
2020-02-01 12:36:57,552*1*Found move:Rd7-d8

2020-02-01 12:36:57,692*2*Child Process Prio Adj: PID 2856 conhost.exe
2020-02-01 12:36:57,692<--1:febr. 01, 2020 12:36:57 DU eubos.main.EubosEngineMain sendBestMoveCommand
2020-02-01 12:36:57,692<--1:INFO: Best move d7d8


Note the PID2856 - this is the oppponent engine. For some reason Eubos prints a log snippet even after that, which are the last two lines above.

So I think Eubos is running as expected, but the comms between it and Arena are somehow problematic. Very strange...

[c_j_bolt]

On my machine (with Arena 3.5), I see debug at the start of each Eubos move like the following:


2020-02-01 11:57:33.359*1*Child Process Prio Adj: PID 4300 conhost.exe
2020-02-01 11:57:33.359*1*Child Process Prio Adj: PID 5536 java.exe
2020-02-01 11:57:33.359*1*Start calc, move no: 5
2020-02-01 11:57:33.359-->1:position startpos moves d2d4 g8f6 b1c3 e7e6 g1f3
2020-02-01 11:57:33.359-->1:go wtime 96436 btime 118604 winc 1000 binc 1000
2020-02-01 11:57:33.375<--1:Feb 01, 2020 11:57:33 AM eubos.main.EubosEngineMain createPositionFromAnalyseCommand
2020-02-01 11:57:33.375<--1:INFO: Position Received, hash = 1350825180686144956
2020-02-01 11:57:33.390<--1:Feb 01, 2020 11:57:33 AM eubos.main.EubosEngineMain moveSearcherFactory
2020-02-01 11:57:33.406<--1:INFO: Search move, clock time 118604


There is some junk here that Eubos shouldn't be printing, but is harmless (the lines starting Feb 01 and INFO:), but notice there are two processes, conhost.exe (which I imagine is running my batch file) and java.exe (which I imagine is actually running Eubos.jar).

Are you not using a batch file? I didn't know Arena can launch Java engines directly - I always install Eubos through a batch file...

eubos_arena_log.txt

Log snippet from my machine, Arena 3.5. Eubos installed via Eubos.bat, which just launches java with the Eubos.jar file.

(12.4 KiB) Downloaded 1135 times

[c_j_bolt]

Hi Gabor,

I did some reasearch and I think I see how you added Eubos into Arena directly as a JAR file. Even when I do this I am able to see the PVs from the start, it's just that I no longer see the two processes - I also see Eubos taking 1012 Mb in Arena, as you described earlier. This is definitely because it is reporting the entire JVM size, not just what Eubos is using. I will invetstigate this configuration with a Java profiler. Using this method it doesn't seem possible to configure the JVM to constrain the heap?

2020-02-01 13:11:14.570*1*Child Process Prio Adj: PID 6376 conhost.exe 2020-02-01 13:11:14.585*1*Start calc, move no: 18 2020-02-01 13:11:14.585-->1:position startpos moves b1c3 c7c6 g1f3 e7e6 e2e4 f8b4 f1e2 b4c3 b2c3 g8f6 e4e5 f6d5 e1g1 e8g8 c1a3 f8e8 f3d4 d5f4 2020-02-01 13:11:14.585-->1:go wtime 113358 btime 112545 winc 1000 binc 1000

[Gabor Szots]

I installed Eubos directly, selecting its jar file, then adding the appropriate command line. Generally I do not use bat files.

The memory use reported by Arena never exceeds 1200 MB's (if that is what you mean by constraining the heap).

[Gabor Szots]

I guess I have discovered the reason for the missing PV and other data. I have UCI filter (to be found amongst general engine UCI settings) switched on. I switched it off temporarily and now I can see PV, nps, hash usage immediately, not only from depth 8.

[c_j_bolt]

Ok, that is good to know about the UCI filter. I am now running with a similar configuration to you and will try to reproduce the issue where Eubos hung after 120 games. I didn't realise engines could be installed directly under the 'Engines > Manage > Details' tab. I am running with command line -Xmx512m -Xms512m and I still see the process takes up to around 1100Mb of RAM. This is unexpected. I will look into that.

Edit: I looked into it with a Java profiler - the command line parameters are passed to Eubos.jar and not into the JVM! That is the reason the heap is not constrained. this can be seen from my profiler screengrabs. the first shows how the args from the command line are not passed to the JVM:

Shows how the -Xms512m is not passed to the JVM, hence the heap size isn't constrained.

eubos_direct_arena_profiler.png (38.86 KiB) Viewed 43306 times

The second shows the true usage of Eubos of the availlable heap, with time:

Shows the heap usage and CPU time (including garbage collection) of Eubos on my PC, from the Java profiler

eubos_direct_arena_profiler_heap.png (95.08 KiB) Viewed 43306 times

We are definitely seeing the same behaviour. I'll try and find out if there is some way of configuring the heap max size when Eubos is installed directly in Arena, without a batch file. In the mean time, if you did feel the need to constrain the heap availlable, i suggest using a .bat file.

Further edit: There are tools online that would allow me to repackage the JAR file into an executable that can set the JVM heap size before the JAR is executed, this would allow using a normal .exe file with Arena and not having to worry about anything, I may investigate providing binaries like that in a future release.

[c_j_bolt]

Hooray! I can see Eubos v1.0.2 has a Blitz rating on the CCRL, currently 1201, lots of scope for improvement! Thanks very much guys for taking the time to include it in your testing, I really appreciate it, it really makes me feel part of the computer chess community

[Graham Banks]

Hooray! I can see Eubos v1.0.2 has a Blitz rating on the CCRL, currently 1201, lots of scope for improvement! Thanks very much guys for taking the time to include it in your testing, I really appreciate it, it really makes me feel part of the computer chess community

[c_j_bolt]

I've been working on some new builds of Eubos and am now happy to release a new version, v1.0.5 (I didn't bother to promote the last couple).

I've not really improved the algorithms, but I have done a lot of optimisation and corrected a couple of defects (including one in the move timing algorithm which meant it settled for slightly losing scores quite happily when playing as black - slightly embarrasing!)

I have run a lot of tests against similar engines in Arena and reckon doubling the speed has added about 100 to 120 ELO points, which would now put it at about 1325. I don't know what the ettiquette is regarding asking for a new version to be tested, but I have put a lot of work into this and I definitely believe Eubos is a good deal better than it was. Hopefully one of you CCRL testers can add it in for testing - you could always delete the existing entry for v1.0.2 on the rankings? I'm very wary of not wanting to pollute the rankings with incremental releases of weak engines!

Opponent ELO Points Games Pts % Enxadrista 1199 143.5 200 72 Dragontooth 1231 76.5 100 77 KillerQueen 1280 66 100 66 Cerulean JS 1294 47.5 65 73 uMax 1.6 ? 34.5 50 69 Gladiator 0.0.7 1331 83 140 59 Nanook 0.17 1389 57.5 136 42

JAR file available at https://github.com/cjbolt/EubosChess/re ... tag/v1.0.5

[Sergio Martinez]

Thank you very much Chris