-
Notifications
You must be signed in to change notification settings - Fork 298
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updated optimum time #556
base: next
Are you sure you want to change the base?
Updated optimum time #556
Conversation
increasing optimum time
update to sf current value
1+1 cpu no TB
1+1 gpu both using syzygy 6 man
It appears this is may be weaker than my previous optimum time PR, since results aren't quite as good and this should also have tilps +50 elo gain history patch in it. It is still more sensical time management than stock since you don't need to use slow mover 120. And is more of what everyone seemed to want in the comments of the last PR. |
src/UCTSearch.cpp
Outdated
@@ -407,7 +407,7 @@ Move UCTSearch::think(BoardHistory&& new_bh) { | |||
// set up timing info | |||
|
|||
Time.init(bh_.cur().side_to_move(), bh_.cur().game_ply()); | |||
m_target_time = (Limits.movetime ? Limits.movetime : Time.optimum()) - cfg_lagbuffer_ms; | |||
m_target_time = (Limits.movetime ? Limits.movetime : (int)(1.5*Time.optimum())) - cfg_lagbuffer_ms; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1.5 * Time.optimum() probably should also be limited by Time.maximum() - otherwise if maximum is > 1 second, but less than 1.5 * Time.optimum() - the target time will waste some of the time.
(The previous place the multiplier was did this, it just didn't get carried over to this new location.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I patched this now
I tried to gather some data to decide whether 1.5 was a good multiplier or not. Results are a bit strange. |
ensure not target time not over max time so pruning will still work if max time cuts search off early
People use sm 120 to 150 for optimal time at 2+2 vs 5+5, so thats anywhere from 40 to 80% increase of sm that seems to be optimal... |
m_max_time = Time.maximum() - cfg_lagbuffer_ms; | ||
|
||
if (Limits.movetime) { | ||
m_target_time = Limits.movetime; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should have the lagbuffer subtracted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Limits.movetime did not have it subtracted before, so I didn't change that at all, since I'm only trying to optimize real TC
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the previous code was m_target_time = (move time conditional dependent expression) - lagbuffer.
So lag buffer was applied regardless of movetime or not.
if (Limits.movetime) { | ||
m_target_time = Limits.movetime; | ||
} else { | ||
m_target_time = std::min( (int64_t)(1.5*Time.optimum()), m_max_time ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 spaces on the indent here?
1+1 gpu both using syzygy 6 man compared to optimal 120 slow mover
after I fixed by putting the min(1.5*optimum,max). seems like it gained a little elo, but still a regression from v8. The time looks pretty similar so I think it's other changes in the next branch doing this. |
increasing optimum time