5% less time on first move.

[xoto10]

Stockfish appears to take too much time on the first move of a game and then not enough on moves 2,3,4... Probably caused by most of the factors that increase time usually applying on the first move.

Attempts to give more time to the subsequent moves have not worked so far, but this change to simply reduce first move time by 5% worked.

STC 10+0.1 :
LLR: 2.96 (-2.94,2.94) <0.00,2.00>
Total: 78496 W: 20516 L: 20135 D: 37845
Ptnml(0-2): 340, 8859, 20456, 9266, 327
https://tests.stockfishchess.org/tests/view/663d47bf507ebe1c0e9200ba

LTC 60+0.6 :
LLR: 2.95 (-2.94,2.94) <0.50,2.50>
Total: 94872 W: 24179 L: 23751 D: 46942
Ptnml(0-2): 61, 9743, 27405, 10161, 66
https://tests.stockfishchess.org/tests/view/663e779cbb28828150dd9089

Bench 1876282

[xoto10]

Worth noting that tests for -4%, -6% and -10% have all failed STC.

The -5% tests were convincing, and tunes have suggested about -5% for the first move ... but you'd expect -4% or -6% to be roughly similar. Not sure what to make of this ...

[vondele]

This doesn't seem to be needed for the current PR

[xoto10]

Sure. I think we could remove all the originalPly stuff as well, but have pushed a version just removing this array.

[xoto10]

Will do a clang format.

[xoto10]

Moving my notes in the PR text to here:

Note: stc and ltc have passed for an alternative way of coding a time reduction on the first move, adjusting the time boost calculated in search.cpp while this current PR adjusts the optScale in timeman.cpp, see xoto10/stockfish-xoto10@c43425b...90e8451

Note 2: There is also https://tests.stockfishchess.org/tests/view/6641a2daf9f4e8fc783cb98c which uses a simpler way of detecting the first ply of the game.

[xoto10]

Too late for TCEC, but I'm also hopeful for xoto10/stockfish-xoto10@c43425b...1f8670d
and https://tests.stockfishchess.org/tests/view/66424374f9f4e8fc783cba47 as simpler and more general solutions, be interesting to see if they produce something ...

[xoto10]

Writing down some thoughts:

I think part of the problem doing tm work is that the master code is currently optimised fairly well for ltc, but gives too much time at stc, so any change that happens to reduce time use has an improved chance of passing at stc, even if it's not generally useful. I wonder if this has any implications for appropriate scaling beyond ltc.

Regarding the spikes in time allocated for individual moves, there is obv only one first move in each game, so code changes here perhaps perform roughly the same at different tc (but see next point). I suspect there are more time spikes in shorter tc games, and to higher levels (as much as 20x is possible, multiplier going from 0.5 to 10), so trying to reduce the size of spikes throughout the game might prove tricky to pass at different tc.

[TierynnB]

Randomly saw this, I did a change for no increment tc when it reached below 1 sec which had a big impact. Thought you might find it interesting if ur looking at different tcs.

#5112 (comment)