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

Optimisation idea: skip showing info on the command line #704

Open
Wak017 opened this issue Jun 15, 2018 · 1 comment
Open

Optimisation idea: skip showing info on the command line #704

Wak017 opened this issue Jun 15, 2018 · 1 comment

Comments

@Wak017
Copy link

Wak017 commented Jun 15, 2018

Title says it all, almost.

I saw on the forum that the new lc0 was performing around 50 games in 3 minutes, a huge progress relative to what most contributors do right now. With these infos I calculated that if infos are still shown on the command line for every move played, like they are for the main project, there should be a lot of prints. Quick mafs.

So it came to my mind that maybe the prints on the command line are taking some process and can slow down the whole thing (I'm talking about the info depth nps score etc). Yes, it may not seem like it, I know, but I learned the hard way that printing can slow down a running program when there is a good amount of prints per second (which the new lc0 is guilty of doing)**. I had a project recently that the whole thing would take 35 minutes to run on my PC, and when I took away all the prints on the command line the whole thing was taking 2 minutes. Of course there were a lot of differences between my project and this one, being 1. My project was in java (Eclipse), 2. I was printing everytime one of my 2^21 nodes connected. So, printing was slowing everything down a LOT.

Of course, with this idea I'm not expecting the whole thing to go much faster, but on the other hand, contributors don't really need to see all these infos, so it may be turned off by default, with the exception of the info that a game finished in x minutes and y seconds. It's a relatively easy optimization fix I would suppose, also, so why not try it?

**Note that I am still only participating on the main network right now, so this may have been already taken care of and I'm not aware of it. If so, ignore what I just said.

@simlu
Copy link

simlu commented Feb 24, 2019

Gist here is that it would be nice to have different log level. This might or might not have an impact on performance.

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

No branches or pull requests

2 participants