Greetings and new Eubos chess engine

[c_j_bolt]

Thanks very much. The provisional result is a little better than I was expecting, but I had seen Eubos v2.10 get better than a 60% win rate against BikJump (2102) over 550 games.

This is the beauty of the CCRL testing you guys do. I can run many games against a single engine easily, but I never test for breadth against more than a couple of opponents at each new version. I normally just try to get a statistically significant result against a CCRL benchmarked engine, which typically takes me a couple of days.

Thanks again,
Chris

[c_j_bolt]

Hi all,

Just wanted to announce Eubos v3.0. It's the first major release I've made for a couple of years. I've updated the search algorithm to a negamax implementation - found in a O'Reilly textbook on computer AI.

I've given it a lot of testing at 12:0+8, circa 7000 games (takes an age at that control!). Against Dragon 4.6 it holds it's own, with about a 48% win rate. So I reckon Eubos is now around the low 2400s.

To get in any stronger I am either going to have to rewrite the move generation (I'm loathe to do this as it is Eubos original) or improve the evaluation function (time consuming, frustrating, also Eubos original). So I'm going to take a breather for a while, I think. I might write some new tools for blunder detection and scripting self-play instead of direct engine development.

[Gabor Szots]

Hi Chris,

I don't understand what you write about hash size at your page. Could it be that even if I set hash to 256 MB it will use more?

[c_j_bolt]

Previously, if the hash size was set to 256MB, it used only 134,217,728 of the availlable 262,144,000 bytes. I.e. 51.2% of the table size availlable.

This was because I used a bit mask to truncate the zobrist key, rather than using a modulo division (which is really what I should have done from the start). I.e. 256MB is 0xFA00000, so I used the nearest power of 2 bit mask below this value, 0x7FFFFFF to truncate the 64 bit zobrist key. That was a needlessly wasteful thing to do just to save a single division from happening!

It won't use more than 256MByte for the hash table. The engine itself does use more for its look up tables etc. The Java heap mimnimum allocation when it is running is like 265MB, thats 256MB for the hash table and about 9MB for the other LUTs stored on the java heap.

The process might use more because it holds all the memory for the Java virtual machine that runs the engine, but this is not related to chess in any way.

I recently got a few Raspberry Pi Zeros to run tests on. That wasn't a great idea. I thought they would be good as they have four cores and therefore could conceivably run 4 games concurrently in self-play. Unfortunately they only have 512MB of RAM, and that isn't enought to run 8 instances of Eubos, even with a miniscule 4MB hash! In that configuration I can only really manage 2 concurrent games on each Raspberry Pi.

[Graham Banks]

Roughly how much stronger do you estimate 3.0 to be?

[Gabor Szots]

Roughly how much stronger do you estimate 3.0 to be?

I reckon Eubos is now around the low 2400s.

[Graham Banks]

Roughly how much stronger do you estimate 3.0 to be?

I reckon Eubos is now around the low 2400s.