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
Looking for advices
Moderators: hgm, Rebel, chrisw
-
- Posts: 2488
- Joined: Tue Aug 30, 2016 8:19 pm
- Full name: Rasmus Althoff
Re: Looking for advices
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.xr_a_y wrote: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.
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.
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Looking for advices
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.
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.
-
- Posts: 2488
- Joined: Tue Aug 30, 2016 8:19 pm
- Full name: Rasmus Althoff
Re: Looking for advices
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 wrote:What I tried was c++11 std::array so more or less the same as C array I think.
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Looking for advices
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.
-
- Posts: 4052
- Joined: Thu May 15, 2008 9:57 pm
- Location: Berlin, Germany
- Full name: Sven Schüle
Re: Looking for advices
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:xr_a_y wrote: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.
Code: Select all
Move moveList[256];
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.
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Looking for advices
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.
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.
-
- Posts: 1871
- Joined: Sat Nov 25, 2017 2:28 pm
- Location: France
Re: Looking for advices
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
Best regards