Looking for advices

[Pio]

Hi Vivien!

What I do in my engine is to have one move array shared for all plies. I then have an index array telling where each ply starts. In that way you can use all the space and do not have to account for the extreme case nr of moves.

/Pio

[Ras]

if the container if 128 moves sizes, speed is the same than with vector BUT in some case 128 moves is not enough. Using bigger size even around 150 or 160 is slow than with vector.

For fixed size, you may need something like 300 moves to be sure with pathological positions (but those don't happen in real games). Much less than that in QS, of course.

Did you benchmark what happens if you don't use containers, but raw C style arrays? You can just put them on the stack in your search and QS.

[xr_a_y]

What I tried was c++11 std::array so more or less the same as C array I think.

I really need to try Pio advice although SMP version seems not straightforward (at least introduce an atomic counter or a lock)... I'll get back to you on this subject.

Thanks.

[Ras]

What I tried was c++11 std::array so more or less the same as C array I think.

Pretty much, except if you accidentally perform a copy (maybe via return-by-value) where you'd hand over a pointer in C. However, where did you put the arrays, stack or heap?

[xr_a_y]

On the stack. I am pretty sure there is no useless copy of the move list. In case of a missing reference, RVO will be used most of the time is such cases.

[Sven]

On the stack. I am pretty sure there is no useless copy of the move list. In case of a missing reference, RVO will be used most of the time is such cases.

Optimizing an Elo ~2000 engine for speed is simply a waste of time and energy, it is the wrong approach. I'd suggest to concentrate on other more important things first, and keep the basic infrastructure of the engine as simple as possible in a way that is "obviously correct". So I would not bother with issues like which container to use for a move list, which is the optimal container size, constant or growing, allocated statically or dynamically, etc. If you have a "Move" object (or structure) then I would simply write:

Code: Select all

Move moveList[256];

and maintain this simple C array on the stack whenever you deal with move generation. Works perfectly, you see immediately what happens, and it is fast enough for the current development stage. Of course you can wrap this in a "MoveList" class if you like, there is certainly a benefit of it but it is not huge.

You can always gain a few Elo points of strength by making the engine faster in terms of NPS. But there are tight limits to that, for the following reasons (in short words: the gain is constant and does not grow with increasing depth).

As you have seen in your recent tests (here I refer to your other thread) searching one ply deeper adds about 40-80 Elo points, depending on several factors (e.g. weaker engines get more benefit per ply than stronger ones, and the additional gain reduces with increasing depth). When assuming a decent effective branching factor (EBF) of around 2 (most Elo 2000 engines are far off, though), even doubling the overall search speed would only return a strength improvement of around 40-80 Elo points. Now with an EBF >2 (more realistic), doubling the speed of the move generation and technical move processing (which takes at most 50% of the overall runtime costs per node - usually more like 10-20% or less!) would return how many Elo points? Certainly much less than 20 under my assumptions. And most performance tweaks do not double the move generation speed (+100%) but improve by, say, 20-30% or so. So what is the benefit, considering the risk of introducing new bugs when optimizing for speed?

In contrast to that, improving the search (e.g. move ordering, pruning, ...) will usually lower the EBF, and from there you actually get the highest gains. Example: Engine has an EBF of 3.0 and reaches depth 10 with a given TC. With a better EBF of about 2.7 it can reach depth 11 in the same time, depth 12 with EBF=2.5, depth 13 with EBF=2.3, depth 14 with EBF=2.2, and with EBF=2.0 you can already reach depth 16. Here you see that improving the EBF by a small amount leads to quite huge strength improvements, and - more important - the resulting gain *increases* with longer TC. So it pays off to investigate more in this area.

[xr_a_y]

I totally share you ideas on the speed question, looking for speed is not my main goal now, I just question things that's seems suspicious and have fun programming.

I have focus on search EBF (mainly tuning LMR and aspiration window) and evaluation also on the past few weeks starting just with PSQT and adding some "space" thing, trapped piece, bad bishop, rook on open file successfully (increasing overall elo by nearly 200, a large part of if being not drawing games that are winnable). I'll check that during next HGM's tournament.

[xr_a_y]

I've just started some tests against Horizon4.4 (around 2300elo) and at very fast TC (5sec for 40 moves) Weini (1 thread) is not so bad : 51-27-22 for Horizon (this is around -85 for Weini). Looking forward for the next tournament too see how things are going at blitz TC.

Best regards