How to improve further ?

[nevatre]

You might be correct, but I hope not. I was looking forward to some benefit after all the work I've done converting to bitboards

[Jan Brouwer]

But I think there is another important point to consider. According to the results of your engine that I could find with a quick search (e.g. OpenWar, WBEC New Engines Qualify), the engine currently is around 1600 ELO or even below this, and for me this is a strong indication that there may be some major problems already in the *present* code. I think that a properly written engine, even without TT and nullmove, should not have less than 1600 ELO.
Sven

I agree. It seems your (Roger's) engine is not strong enough considering its feature set.
If your goal is to have a strong engine, it is important to keep you code as bug-free as possible (with bug-free here I also mean avoiding sub-optimal implementation of algorithms). It is so easy to make very minor mistakes which can have a large influence on playing strength.
These problems may well overwhelm any future improvements that you try.
My suggestion is: start simple, try to measure strength improvement after every change you make, and only keep those that work.

Jan

[Rogerb]

Hi,

ID also makes the engine flexible to various time controls: at any moment you have the availability of a "best move"

Roger

[Rogerb]

I tend to agree with you both
I should first fully optimize the engine before starting on Hash tables and null move pruning (Allthough this is what I already tried a lot before, with minor improvements however, but at least some ..)

For instance I experimented a lot with search reductions and extensions, but it didn't bring much. Also I spend time in analyzing lost matches against equal engines and try to learn from that.

Sven: I never did any analysis with Perft, but I will try to do it.

Roger

[bob]

With fast and reasonably priced 64 bit processors, there's no excuse not to have a bitboard program. The only point of contention is how extensively bitboards should be used.

I always thought that the fact that it is an enormous amount of high complex work, and in intself brings you approximately nothing, is a pretty good excuse...

If you are talking about bitboards, they don't bring "approximately nothing". There are things that are extremely fast in bitboards, which makes them worthwhile. For example, "Is this pawn passed?" is one AND instruction. Do that in a mailbox program. How much it is worth is another issue, but it is clearly faster on 64 bit processors, purely based on "data density".

[hgm]

There are things that are fast, but you really must want to do those thngs and do a lot of them to earn back the overhead. On a simple engine like the one we are talking about I don't think there would be enough such things to make it pay off.

[hgm]

You might be correct, but I hope not. I was looking forward to some benefit after all the work I've done converting to bitboards

Well let us know how much Elo it brought you!

[Uri Blass]

Hi all,

my chess engine RBrChess is one of the weaker engines around. I,m now stuck a little on how to improve further.

It does have:
- a quite extensive evaluation function with piece-square tables, king safety and more ..
- iterative deepening
- quite extensive move ordering
- pondering support

But it doesn't have:
- transposition tables
- null move pruning
- bitboards (now use 12x12 matrix of integers)
- ....

Question:
Has anyone a clue of how much ELO you can gain with these 3 (or other) improvements ?
I would guess 100-200 ELO with hash tables, 50-100 ELO with null move pruning.

Thanks, Roger

The first two are essential features. transposition tables are not that hard to add, and null-move search is really easy. Probably in a full game, null-move search will help the most, although transposition tables are the very reason for doing an iterative-deepening search in the first place, so you might gain a significant amount of speed due to the improved move ordering the trans/ref table will provide.

How do you even *do* IID without a hash table?

In searches without hashtable IID is even more important.

I found in 90s a trick there which would've been great for dedicated computers with just 4KB ram and a tad more ROM, to improve move ordering major league.

Hashtable kills all that though.

In 90s of course a lot of all this didn't get observed as most engines, not crafty - it was one of the exceptions back then, they had a branching factor of 10.0

The initial fritz 5.16 from 1997 had a b.f. of 10.0 or so above 10 ply.
Schach 3.0 also if you was lucky 10.0 and so on. All that to see tactics better.

At such huge branching factors CPU power initially seems much more important then than improve the b.f. a little.

It was around 1999 that everyone started to get concerned about b.f.
Note i had posted that already a few years before.

IID is another such typical trick that everyone knew, but also for diep first 10 plies IID is just not even break even, as we already have that hashtable and as Bob correctly notices ID.

As we get nowadays of course far above 10 ply, which Diep didn't get before 1999, such techniques are more relevant now.

So as soon as you refer to searching without hashtable you should also mention that most likely in such case you don't have very fast cores to your avail

Vincent

I remember that Genius3 that is from 1994 had branching factor near 3
even after many hours of analysis.

I do not know about most engines but I think that it is the opposite.

Fritz was one of the exceptions and the reason is that the programmers did not care about time control that is slower than the ssdf games.

Uri

[JVMerlino]

Don't be concerned with the amount of Elo points added; whatever rating improvement that will come, will come.

Having a move/score transposition table is an immense improvement. Even if the score portion of an entry is ignored (no pruning), the move ordering by itself produces far more efficient searches. And in the endgame, a transposition table with pruning can easily triple the obtainable search depth.

A null move pruning search is very good improvement, although the overall benefit can be reduced by other techniques like LMR and related depth reductions.

With fast and reasonably priced 64 bit processors, there's no excuse not to have a bitboard program. The only point of contention is how extensively bitboards should be used.

Not sure about this last bit, but the rest is definitely true.

From my own recent experience improving Myrddin from the first release, I can say that adding the following features (listed in no particular order)were a huge part of an ELO increase of about 400 points (~1300 to ~1700):

-- null move
-- transposition tables
-- aspiration window
-- late-move reductions (LMR)
-- killer moves
-- history heuristic

Depending on what time controls you test at, improving time management can also give a big gain in points if your current system is flawed.

jm

[bob]

Hi,

ID also makes the engine flexible to various time controls: at any moment you have the availability of a "best move"

Roger

Yes, but without hashing, it simply wastes time, since your 2 ply search takes about as long as it would if you started at 2, rather than starting at 1. The trans/ref table carries information from iteration to iteration to make them go faster. easy time control logic is a second-order effect of course, and is valuable. But not without hash tables.