Picked from official branch. No functional change.
Steamline a bit the implementation of skill levels. As a side effect we can retire MultiPV global and use a local variable instead. No functional change.
- Currently broken - Never been really useful - Does not work well with new splitting model Verified for no regression at STC with 3 threads: LLR: 2.96 (-2.94,2.94) [-6.00,0.00] Total: 81905 W: 12122 L: 12381 D: 57402 No functional change
Bitboard init code is already noteasy to follow, so don't make it even harder using 'smart' code. Also reindent a while loop in standard way. No functional change.
There is no reson to artificially limit the pv_instability rule below a max depth. Spotted by Uri Blass bench: 7634225
Passed STC LLR: 2.96 (-2.94,2.94) [-1.50,4.50] Total: 15687 W: 3352 L: 3199 D: 9136 and LTC (tested in 'parameters tweak' mode) LLR: 2.95 (-2.94,2.94) [0.00,4.00] Total: 27983 W: 5046 L: 4797 D: 18140 bench: 7634225
After earlier patch this condition becomes redundant and can be removed. Spotted by Joona Kiiski. No functional change.
* /boot/common was removed from Haiku * The equivalent path now that package management has been implemented is /boot/system/non-packaged No functional change.
After recent patch 55a3e0a, we have an assert searching on: 5rk1/4K1pp/8/5PPP/8/8/8/1R6 w - - 12 1 Assert is: Assertion `-VALUE_INFINITE <= alpha && alpha < beta && beta <= VALUE_INFINITE' failed. The patch fixes it. bench: 8094100
Now that TT cluster ize is 32bytes and we address TT table by cluster, it is possible to raise the limit to 64GB while still using a uint32_t to index the cluster within teh table. No functional change.
This patch compresses TTEntry to 10 bytes and resizes a cluster from 4 to 3 slots, so that cluster size is 10 X 3 + 2 = 32 bytes where last 2 bytes are padding. Patch gives and advantage under high hash pressure where we can reach +10 ELO with 4 MB Hash at 60secs TC: ELO: 10.24 +-2.0 (95%) LOS: 100.0% Total: 40000 W: 7830 L: 6651 D: 25519 And is neutral with low hash pressure. To note that now hash key size is just 16bits opening the door for many more hash collisions, eventually big number of tests under many different conditions seem to confirm that this is not so dangerous as it seems. Idea from Ron Britvich Code reworked by Marco Costalba and Joona Kiiski Tested with high hash perssure. Passed STC (16MB hash size) LLR: 2.95 (-2.94,2.94) [-1.50,4.50] Total: 14066 W: 2445 L: 2308 D: 9313 and LTC (8MB hash size) LLR: 2.96 (-2.94,2.94) [0.00,6.00] Total: 8827 W: 1297 L: 1161 D: 6369 Tested also for no regression at 128MB hash size: LLR: 2.94 (-2.94,2.94) [-3.50,0.50] Total: 18451 W: 3286 L: 3177 D: 11988 Bench: 8095369
This reverts commit ce1c260 It seems we haev an important nps drop in endgames with high threads. Reported by fastgm, testing with 16 threads. bench: 7710548
No functional change.
The assert: assert(ttValue != VALUE_NONE); Could fire for multiple reasons (although is very rare), for instance after an IID we can have ttMove != MOVE_NONE while ttValue is still set at VALUE_NONE. But not only this, actually SMP is a source of corrupted ttValue and anyhow we can detect the condition: ttMove != MOVE_NONE && ttValue == VALUE_NONE even north of IID. Reported by Ronald de Man. It is so rare that bench didn't change. bench: 7710548
No functional change.
It seems a more natural to place this function there. No functional change.
Also dropped some temporary variable: compiler is more than able to push on stack temp values by itself (verified). No functional change.
Remove from the search this special case and apply null search and razoring also in mate positions. Tested in no-regression mode and passed both STC LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 65431 W: 10860 L: 10810 D: 43761 and LTC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 34928 W: 4814 L: 4713 D: 25401 This patch kicks in only in mate positions and in these cases it seems beneficial in finding mates faster as Yery Spark measured on the Chest mate suite: Total number of positions 6425 Fixed nodes 200K per position master: 1049 new: 1154 And also the 5446 'hard' positions again with 2000K nodes (those not found by both engines in 200K nodes): master: 1069 new: 1395 bench: 7710548
Tested in no-regression mode and passed both STC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 17919 W: 3103 L: 2978 D: 11838 and LTC LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 31460 W: 4414 L: 4308 D: 22738 bench: 7709279
It seems this flag is only for gcc and yields a warning under OSX Mavericks: clang: warning: argument unused during compilation: '-ansi' No functional change.
Here MSVC is worried that StepAttacksBB[PAWN][psq] could overflow, so change psq initialization to clarify psq is always less than 64. No functional change.
Code style paranoid in action here :-) No functional change.
Improves readibility and possibly speed. No functional change.
Tested in no-regression mode, passed STC LLR: 2.96 (-2.94,2.94) [-3.00,1.00] Total: 14477 W: 2493 L: 2362 D: 9622 and LTC LLR: 2.95 (-2.94,2.94) [-3.00,1.00] Total: 51964 W: 7091 L: 7013 D: 37860 bench: 7875814
This name is more accurate, since that function evaluates only one outpost in every call. No functional change.
Passed both STC LLR: 2.95 (-2.94,2.94) [-1.50,4.50] Total: 15413 W: 2670 L: 2530 D: 10213 And LTC: LLR: 2.95 (-2.94,2.94) [1.00,6.00] Total: 66908 W: 9398 L: 8960 D: 48550 Bench : 7859385
No functional change.
Don't take the split lock if we don't have available slaves (about 30-40% of times). This new condition allows to retire the now redundant one on number of threads. No functional change.
Although signature allows an int: int isspace( int ch ); The behavior is undefined if the value of ch is not representable as unsigned char and is not equal to EOF. See http://en.cppreference.com/w/cpp/string/byte/isspace http://www.greenend.org.uk/rjk/tech/cfu.html This is really a tricky corner case of C standard! Spotted and reported by Ron Britvich. No functional change.
Use instead: (ss-1)->currentMove == MOVE_NULL No functional change.
Use (move != MOVE_NONE) condition to filtering out updating gains at root. bench: 8454456
Split previous patch in 2 steps: first remove the MOVE_NULL hack, then retire nullChild. The first step is a prerequisite for second one and affects bench. The second step (next patch) just removes nullChild without affecting bench. bench: 8205159
Should be a non functional change, but for some reason bench is changed. bench: 8454456
No functional change.