The start time is the time point we start our clock and in
an ideal case it should be set to the same clock running in
the tournament manager when it sends to the engine the 'go'
UCI command.
Currently it is set at the beginning of MainThread::think()
but this means we have not accounted for the time to wake
up the thread and the time it takes start_thinking to join()
the main thread, possibly waiting for the slave threads to finish.
In standard conditions we are talking of very few msecs, but
with high number of cores and high time pressure, it is
difficult to get a reliable estimate.
So move it much earlier, just before processing the 'go' command.
bench: 8397672
The SPRT LTC test on 3 threads was like this:
LLR: 2.95 (-2.94,2.94) [0.00,5.00]
Total: 25653 W: 3730 L: 3521 D: 18402
The ELO STC test on 3 threads was like this:
ELO: 6.79 +-3.4 (95%) LOS: 100.0%
Total: 13716 W: 2435 L: 2167 D: 9114
The ELO STC test on 23 threads was like this:
ELO: 0.77 +-5.3 (95%) LOS: 61.1%
Total: 4970 W: 765 L: 754 D: 3451
bench: 8397672
Crash is due to slave thread accessing main thread
data while exiting.
Fix it in the proper way makeing slave threads
independent from main state.
No functional change.
In Thread::idle_loop() we now access main thread data,
namely Threads.main()->thinking
So upon exit we have to ensure main thread is the last
one to be deleted. It can be easily reproduced setting
more then one thread and then quitting.
This bug happens also in original lazy_smp but for some
reason remains hidden.
Although a crash, this should not compromise TCEC version
because it occurs only upon exiting the engine.
No functional change.
Retire slavesMask. We don't need it. It si enough
'searching' and 'thinking' flags.
Further simplification is still possible, perhaps
we could use a single flag.
No functional change.
Start all threads searching on root position and
use only the shared TT table as synching scheme.
It seems this scheme scales better than YBWC for
high number of threads.
Tested at very LTC (120+0.1) with 23 threads
ELO: 35.52 +-9.6 (95%) LOS: 100.0%
Total: 1109 W: 183 L: 70 D: 856
Tested at LTC with 23 threads
ELO: 34.41 +-9.9 (95%) LOS: 100.0%
Total: 1094 W: 184 L: 76 D: 834
Tested at LTC with 7 threads
ELO: 8.76 +-5.0 (95%) LOS: 100.0%
Total: 5000 W: 735 L: 609 D: 3656
Tested at STC with 7 threads
ELO: 16.76 +-5.4 (95%) LOS: 100.0%
Total: 5000 W: 899 L: 658 D: 3443
Bench: 8397672
Apply bonus for the prior CMH that caused a fail low.
Balance Stats: CMH and History bonuses are updated differently.
This eliminates the "fudge" factor weight when scoring moves. Also
eliminated discontinuity in the gravity history stat formula. (i.e. stat
scores will no longer inverse when depth exceeds 22)
STC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 21802 W: 4107 L: 3887 D: 13808
LTC:
LLR: 2.96 (-2.94,2.94) [0.00,5.00]
Total: 46036 W: 7046 L: 6756 D: 32234
Bench: 7677367
Add Travis CI support to GitHub repo.
After every push to master, Travis will build
the sources directly from GitHub repo according
to .travis.yml and verify everything is ok.
No functional change.
Fix issues after a run of PVS-STUDIO analyzer.
Mainly false positives but warnings are anyhow
useful to point out not very readable code.
Noteworthy is the memset() one, where PVS prefers ss-2
instead of stack. This is because memeset() could
be optimized away by the compiler when using 'stack',
due to stack being a local variable no more used after
memset. This should normally not happen, but when
it happens it leads to very sublte and difficult
to find bug, so better to be safe than sorry.
No functional change.
When changing 'search' and 'splitPointsSize' we have to
use thread locks, not split point ones, because can_join()
is called under the formers.
Verified succesfully with 24 hours toruture tests with 20
cores machine by Louis Zulli: it does not hangs.
Verifyed for no regressions with STC, 7 threads:
LLR: 2.94 (-2.94,2.94) [-3.00,1.00]
Total: 52804 W: 8159 L: 8087 D: 36558
No functional change.
Only refresh TT entry when it's really necessary.
This should give a small speed boost for some machines.
And it's a risk-free change.
No functional change.
Resolves#429
Louis Zulli reported that Stockfish suffers from very occasional hangs with his 20 cores machine.
Careful SMP debugging revealed that this was caused by "a ghost split point slave", where thread
was marked as a split point slave, but wasn't actually working on it.
The only logical explanation for this was double booking, where due to SMP race, the same thread
is booked for two different split points simultaneously.
Due to very intermittent nature of the problem, we can't say exactly how this happens.
The current handling of Thread specific variables is risky though. Volatile variables are in some
cases changed without spinlock being hold. In this case standard doesn't give us any kind of
guarantees about how the updated values are propagated to other threads.
We resolve the situation by enforcing very strict locking rules:
- Values for key thread variables (splitPointsSize, activeSplitPoint, searching)
can only be changed when the thread specific spinlock is held.
- Structural changes for splitPoints[] are only allowed when the thread specific spinlock is held.
- Thread booking decisions (per split point) can only be done when the thread specific spinlock is held.
With these changes hangs didn't occur anymore during 2 days torture testing on Zulli's machine.
We probably have a slight performance penalty in SMP mode due to more locking.
STC (7 threads):
ELO: -1.00 +-2.2 (95%) LOS: 18.4%
Total: 30000 W: 4538 L: 4624 D: 20838
However stability is worth more than 1-2 ELO points in this case.
No functional change
Resolves#422
v = value without ep capture being considered
v1 = value of the ep capture
The correct logic is:
if without e.p. capture we are losing, and the value of e.p is either draw, or win or "loss, but 50 move rule saves us", then we should use the value of ep capture.
Credit and thanks to syzygy1 and lantonov !
No functional change (except with syzygy bases)
Resolves#415Resolves#394
Instead of using hard coded Min and Max values for history,
always adjust the old value slightly downwards before adding a new value.
The adjustment acts like gravity that prevents the value escaping too
far from zero.
Bench: 8020484
Resolves#407
Apart from usual renaiming, take advantage of
C++11 function template default parmeter to
get rid of Eval trampoline functions.
Some triviality fixes while there.
No functional change.
Align the behaviour with reductions. Initially castling moves had to be
treated differently, because the SEE did not handle them correctly. But now it
does.
STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 83750 W: 15722 L: 15711 D: 52317
LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 97183 W: 15120 L: 15115 D: 66948
bench 7759837
Resolves#403
PawnSafePush, with the value S(5,5) proved not "necessary"
possibly due to recent changes to MobilityArea and other changes to Connected bonus.
STC:
LLR: 3.22 (-2.94,2.94) [-3.00,1.00]
Total: 98528 W: 18757 L: 18759 D: 61012
LTC:
LLR: 5.30 (-2.94,2.94) [-3.00,1.00]
Total: 204194 W: 31698 L: 31734 D: 140762
Bench: 7620871
Resolves#396
