Just use the equivalent Ptwist[], renamed in
MapToEdges[] to indicate that gives highest
score to pawns near the edge and then, as
second order, to bottom rank squares.
We currently check onnly first key, while
we shoudl check both, as confirmed by
author on talkchess:
http://www.talkchess.com/forum/viewtopic.php?t=59947&start=30
This bug fix do not change functionality, we simply
find earlier the DTZ entry instead of reload it.
Introducing a new multi-purpose penalty related to King safety, which
includes all kind of potential checks (from unsafe or unavailable
squares currently occupied by some other piece)
This will indirectly detect and reward some pins, discovered checks, and
motifs such as square vacation, or rook behind its pawn and aligned with
King (example Black Rg8, g7 against Kg1),
and penalize some pawn blockers (if they move, it allows a discovered
check by the pawn).
And since it looks also at protected squares, it detects some potential
defense overloading.
Finally, the rook contact checks had been removed some time ago. This
test will give a small bonus for them, as well as for bishop contact
checks.
Passed STC
http://tests.stockfishchess.org/tests/view/5729ec740ebc59301a354b36
LLR: 2.94 (-2.94,2.94) [0.00,5.00]
Total: 13306 W: 2477 L: 2296 D: 8533
and LTC
http://tests.stockfishchess.org/tests/view/572a5be00ebc59301a354b65
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 20369 W: 2750 L: 2565 D: 15054
bench: 9298175
Just use _mm_popcnt_u64() that is available
both for MSVC abd Intel compiler.
Verified on MSVC that the produced assembly
has the hardware 'popcnt' instruction.
No functional change.
Currently, helper threads will only search up to the
specified depth limit. Now let them search until the
main thread has finished the specified depth.
On the other hand, we don't want to pick a thread with
a higher search depth.
This may be considered cheating. ;-)
No functional change.
It seems that icc used our fallback version of popcount.
Now use intrinsics.
icc version 16.0.2 (gcc version 5.3.0 compatibility)
bmi2 compile
uname -r 4.5.1-1-ARCH
20xbench gives a nice speedup
./stockfish-icc-master 2161515 +- 34462
./stockfish-icc-sse42 2260857 +- 50349
I could not find anything documented that is necessary that prepending -mbmi to -mbmi2 gives some benefit.
Instead at
https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html#x86-Built-in-Functions
The following built-in functions are available when -mbmi is used. All of them generate the machine instruction that is part of the name.
unsigned int __builtin_ia32_bextr_u32(unsigned int, unsigned int);
unsigned long long __builtin_ia32_bextr_u64 (unsigned long long, unsigned long long);
The following built-in functions are available when -mbmi2 is used. All of them generate the machine instruction that is part of the name.
unsigned int _bzhi_u32 (unsigned int, unsigned int)
unsigned int _pdep_u32 (unsigned int, unsigned int)
unsigned int _pext_u32 (unsigned int, unsigned int)
unsigned long long _bzhi_u64 (unsigned long long, unsigned long long)
unsigned long long _pdep_u64 (unsigned long long, unsigned long long)
unsigned long long _pext_u64 (unsigned long long, unsigned long long)
and at
https://gcc.gnu.org/ml/gcc/2014-02/msg00204.html
( "... The real optimization comes from being able to use pext
(parallel bit extract), which can implement several bextr expressions in
parallel.")
Apart from that we don't use all -msse -msse2 -msse3 -msse4.2 etc. but just -msse3 (or -msse4.2) only.
As regards to the speedup within noise level - this pull request is actually reversal of mcostalba#198 wherein prepending -mbmi to -mbmi2 was claimed to be 0.3% faster and here (removing -mbmi) gives 0.4% speed gain.
Same initialization logic for both
pawns and pieces.
The advantage of this patch is that we reduce
redundancy and get a single (source) code path
for both cases. This is easier to understand
and to mantain.
Note: This patch makes use of some advanced template
techniques like SFINAE, decltype and the new function
declaration syntax (with trailing return type). This
is not just a show-off, but it is really needed in
this case.
Remove the involved size[] array to get the
sizes from setup_pairs().
Now code it is more self-documenting because each
table is associated with its clear size.
Currently we malloc a single memory
chunk in which we shuffle all kind of
different stuff in a very tricky way,
for instance see PairsData::base[1]
that is a hack used as a pointer to
data instead of an actual array (no
wonder C++ compiler complains!).
This patch rewrites all this in a way
to avoid hacky allocations and instead
to rely on the standard containers to
do their job.
This is the base for future work.
Now, Binomial[k][n] = Bin(k, n), instead of Binomial[k-1][n] = Bin(k, n).
Better document the Pascal triangle:
* Sum the above and the one to the left of it.
* Values outside the triangle are zero. This was not checked for k=n previously,
and the code implicitly relied on zero initialization of Binomial[]. That
reliance was made more confusing by the initial assignment before the loop.
No functional change.
