Beating Fairy-Max 4.8

[Henk]

I am busy for at least two years beating Fairy-Max. But I did not succeed.

So I wonder how difficult is it. For instance would it be enough just to implement a normal alpha beta search and a basic evaluation ?

[mar]

Hmm, I would probably focus on having a bug-free program in the first place.
Just my two cents.

[Dann Corbit]

Hmm, I would probably focus on having a bug-free program in the first place.
Just my two cents.

+1
With an exclamation mark.

Look at the original code of Fruit. It is full of asserts. Look at the asserts carefully. Fabian is proving that his code is correct. It is no surprise that Fruit quickly became a world beater. (Of course Fabian's ability has a large measure in that, just being careful probably won't make you #1 in the world).

If your basis is broken, you won't move forward very well. First make the foundation solid, without cracks.

Trying to do advanced stuff too early is definitely a mistake.

It reminds me of the first rule of optimization:
1. Don't do it.

And the second rule (for experts only):
2. Don't do it yet.

[Henk]

If it is a bug it won't be a trivial one for all perfts and mate searches seams to go well.

By the way my visual studio express versions have no profilers so it makes it difficult to find computational bottlenecks.

[hgm]

It would help a lot if you could judge why your engine loses to Fairy-Max. Does it blunder away material by middle-game tactics? Does it allow Fairy-Max' Pawns to advance too much in the end-game, so that eventually it will have to sac pieces to prevent their promotion? Does it get checkmated in the middle-game because it neglects King Safety? Does it make unprovoked unsound sacrifices (like minor for 3 Pawns or 2 minors for Rook +Pawn)? If it does blunder away material, is it because it searches less deep than Fairy-Max? Each of this would point to a different shortcoming in your engine.

Fairy-Max has only very little in its favor. Mainly that it is fast in terms of nodes/sec (it can be because it is so simple), and that it knows very well when it should start advancing its Pawns. All the rest is very rudimentary. It uses an alpha-beta search with null move and LMR on all non-capture, non-Pawn moves. And it extends the evasion of all checks in the middle-game. The hash table is always-replace, no depth preference at all. There is no other move ordering than that the hash move is tried first. (No killers, no history.) But all nodes do Internal Iterative Deepening (starting at the hashed depth), starting with a 'pre-QS' iteration (which scores move by an MVV/LVA value), to find the 'hash move' for the next iteration. This effectively causes captures+promotions to be searched (in the d=0 QS iteration) before any non-captures, and the MVV/LVA-wise best capture to be searched before all other captures.

The only King Safety is that it gets a penalty for moving his King in the middle game, and moving the Pawn directly in front of the King. The only Pawn Structure is that it gets a penalty for moving a Pawn when there is no Pawn 2 squares left or right of it (for giving up Pawn control over a square). And that Pawns on 6th and 7th rank are worth 1.75 and 2.5 Pawns, respectively, and that there is a bonus for advancing Pawns that increases towards the end-game. And there are (game-stage independent) piece values. That is about it. There is no mobility evaluation.

[Henk]

Do you think you could write a super simple engine that beats Fairy-Max easily ?


Nodes per second of Fairy-Max is at least five times more than Skipper2.

Skipper uses killer moves and non captures are sorted. Also King safety is more complicated.

At this moment Skipper searches two plies less deep than Fairy-Max. For instance it doesn't reduce depth at all when in check.

[Dann Corbit]

If it is a bug it won't be a trivial one for all perfts and mate searches seams to go well.

By the way my visual studio express versions have no profilers so it makes it difficult to find computational bottlenecks.

If your program is bug free, then you will make good progress.

When it comes to making it faster, first make it right, then make it fast.

The way to speed it up will be a change to a better algorithm. Tweaky little hacks don't really accomplish much.

If you want your program to rule the world, you will need to reduce the branching factor.

If you can spend more time on important nodes and ignore useless ones, then your program will prosper.

Easier said than done, of course.

[matthewlai]

Do you think you could write a super simple engine that beats Fairy-Max easily ?


Nodes per second of Fairy-Max is at least five times more than Skipper2.

Skipper uses killer moves and non captures are sorted. Also King safety is more complicated.

At this moment Skipper searches two plies less deep than Fairy-Max. For instance it doesn't reduce depth at all when in check.

If NPS is that much lower and you aren't doing crazy stuff (like using neural networks for eval), it may be time to do some profiling and see where all the time is spent.

Pre-mature optimization is bad, but it never hurts to look at profiling results and see if there's something crazy going on (a bottleneck that may not have ever crossed your mind).

VS 2015 Community Edition is free and includes a profiler. There are also open source options like gprof (if you use Linux, there are way more open source profiling options, and some are very good).

[Dann Corbit]

Take a look at Olithink.
From here:
http://home.arcor.de/dreamlike/chess/

This thing:
http://home.arcor.de/dreamlike/chess/Ol ... 32.src.zip

A single file, 44K.

From http://www.computerchess.org.uk/ccrl/4040/
we see this:
181 OliThink 5.3.2 64-bit 2375 +22 −22 49.3% +6.2 25.6% 741

Fairy Max is about the same as Micro Max according to this:
http://www.open-aurec.com/wbforum/viewt ... =2&t=50723
which would be 400 Elo lower.

I guess that Fairy Max has advanced, but Olithink is almost surely the stronger engine.

[bob]

Hmm, I would probably focus on having a bug-free program in the first place.
Just my two cents.

+1
With an exclamation mark.

Look at the original code of Fruit. It is full of asserts. Look at the asserts carefully. Fabian is proving that his code is correct. It is no surprise that Fruit quickly became a world beater. (Of course Fabian's ability has a large measure in that, just being careful probably won't make you #1 in the world).

If your basis is broken, you won't move forward very well. First make the foundation solid, without cracks.

Trying to do advanced stuff too early is definitely a mistake.

It reminds me of the first rule of optimization:
1. Don't do it.

And the second rule (for experts only):
2. Don't do it yet.

A little too strong a statement IMHO (proving his code is correct). It is a LONG way to "proving a program is correct" from the starting point of "proving array bounds won't be violated" and such. Asserts are a useful debugging tool, but they are not a "proof" of very much at all.