This is a prerequisite for future work and anyhow removes
a state flag, so it is good anyhow.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It is redundant and complicates the already complicated
SMP code for no reason.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
We already do this for locks. Also rename SitIdleEvent
in WaitCond to be uniform with Lunix naming.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
This is the native way done in Windows and we will use it
for future work, so change Linux to do the same.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It has more sense to treat the two evaluation metrics
in the same way.
As a side effect now we use the correct eval margin when
pruning in a SplitPoint node.
No functional change in single thread.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Rewrite sp_search() to have same signature of search()
This is the first prerequistite step toward unification.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Actually it is an error to update back moveCount value after split()
because it is used in update_history() to access movesSearched[]
array. But becasue this vector is not updated in the split point
we end up with an access of stale data.
Bug has been hidden til now because we 'forgot' to update
moveCount before returning from split().
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Mostly suggested by Justin (UncombedCoconut), the 0ULL -> 0 conversion
is mine.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
This patch from Joona greatly reduces move count pruning,
below is the old and new move count limits starting from
ONE_PLY with half-play increment:
Old: 4,5,5,5, 7, 7,11,11,11,19,19,19,35,35
New: 4,5,7,9,12,15,19,23,28,33,39,45,52,59
Surprisingly results are even a bit better at a quite
fast time control.
After 5260 games at 30"+0.1
Mod - Orig: 864 - 806 - 3590 ELO +3 (+- 3.8)
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It seems totally unuseful because killers are not
used to order the moves in qsearch. Although there
is some functionality change, probably just a small
side effect.
After 5656 games on rc
Mod vs Orig: 1007 - 980 - 3669 ELO +1 (+- 3.7)
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
So there is no need to explicitly check for king moves
when detecting prunable evasions.
Perhaps teoretically a very bit slower (I didn't test),
but it is more clear now what evasions we consider prunable.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
A code semplification that could even be a slight increase,
anyhow is a reducing pruning patch, so it is good even
at equal strenght.
After 6342 games
Mod - Orig: 1040 - 974 - 4328 ELO +3 (+- 3.5)
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
And rename in nodes now that we have only one.
After the beta-cut off counters removing we can
get rid also of this one.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
For now keep FutilityMarginsMatrix[] unchanged, in
future we are going to reduce to compensate for extra
margin.
At this moment it is enough we don't have regressions.
After 9694 games on russian cluster
Mod - Orig 1608 - 1578 - 6508 ELO +1 (+- 2.8)
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It will be more clear when we will go to add stuff
apart from king danger itself.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
We don't need that !
We can infere from starting fen string if we are in
a Chess960 game or not. And note that this is a per-position
property, not an application wide one.
A nice trick is to use a custom manipulator (that is an
enum actually) to keep using the handy operator<<() on the
move when sending to std::cout, yes, I have indulged a
bit here ;-)
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
After testing on our russian cluster: +3 elo after 4200 games
So keep it becuase it allows a good semplification.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
When depth < DEPTH_ZERO we store with the same depth all
the positions, use -OnePly instead of -1 for consistency
with depth arithmetic.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
There is no reason to use a variable for this.
Also remove unused DEPTH_ZERO and DEPTH_MAX.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Regression test found the patches to be harmless,
so revert to keep code simpler.
Test1 at 20+0.1: (2500 - 3000) +0 ELO
Test2 at 1+0: (~1000) +2 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
There is a functional change because we now skip
more moves and because do_move() / undo_move() is
well known to be not reversible we end up with a
change in node count, although there is actually
no change but a bit speed up.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
To be uniform across the sources. As a nice side effect
I quickly spotted a couple of needed renames:
captured_piece() -> captured_piece_type()
st->capture -> st->capturedType
Proposed by Ralph and done with QtCreator
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
In root_search() we can compute depth at the beginning
once and for all.
Spotted by Ralph Stoesser.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
We can now set member data as private because is no more
directly accessed.
Should be more clear now.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Move OptimumSearchTime, MaximumSearchTime and
ExtraSearchTime in TimeManager.
Note that we remove an useless initialization to 0 because
these variables are used only with time management.
Also introduce and use TimeManager::available_time()
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Firt step in unifying all time management under
a single umbrella. Just introduced the class without
even member data.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
After razoring, IID, null verification and singular
extension searches we have could have a dirty ss->bestMove,
restore to MOVE_NONE before to enter moves loop.
This should avoid to store in TT a stale move when
we fail low.
Tested together with previous patch that is the
one that gives ELO.
After 1152 games at 1+0 on my QUAD
Mod vs Orig +233 =716 -203 (+9 ELO)
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
