Skip to content
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

Open
wants to merge 4 commits into
base: next
Choose a base branch
from
Open

Updated optimum time #556

wants to merge 4 commits into from

Conversation

jjoshua2
Copy link
Contributor

@jjoshua2 jjoshua2 commented May 7, 2018

increasing optimum time

increasing optimum time
update to sf current value
@jjoshua2
Copy link
Contributor Author

jjoshua2 commented May 8, 2018

1+1 cpu no TB

Score of lczero v8 CPU 120 vs lczeroTime7: 2 - 9 - 6 [0.294]
Elo difference: -152.08 +/- 150.45

1+1 gpu both using syzygy 6 man

Score of lczeroTB v8 id251 SM 120 vs lczeroTime GPU: 19 - 4 - 22 [0.667]
Elo difference: 120.41 +/- 73.57

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.

@@ -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;
Copy link
Contributor

@Tilps Tilps May 8, 2018

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.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I patched this now

@Tilps
Copy link
Contributor

Tilps commented May 8, 2018

I tried to gather some data to decide whether 1.5 was a good multiplier or not. Results are a bit strange.
Seems to suggest it could be higher, maybe even up towards 1.8. But the fact that we take 1 second to decide whether to start pruning starts to hurt when time control runs low, so being more conservative with the multiplier is probably safer.

ensure not target time not over max time so pruning will still work if max time cuts search off early
@jjoshua2
Copy link
Contributor Author

jjoshua2 commented May 8, 2018

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...
J.H Ellis also found optimal SM in his testing a while ago in that range.

m_max_time = Time.maximum() - cfg_lagbuffer_ms;

if (Limits.movetime) {
m_target_time = Limits.movetime;
Copy link
Contributor

@Tilps Tilps May 8, 2018

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.

Copy link
Contributor Author

@jjoshua2 jjoshua2 May 8, 2018

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

Copy link
Contributor

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 );
Copy link
Contributor

@Tilps Tilps May 8, 2018

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?

@jjoshua2
Copy link
Contributor Author

jjoshua2 commented May 8, 2018

1+1 gpu both using syzygy 6 man compared to optimal 120 slow mover

Elo difference: 91.55 +/- 50.53

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants