WB protocol extension: thinking output

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
Greg Strong
Posts: 388
Joined: Sun Dec 21, 2008 5:57 pm
Location: Washington, DC

Re: WB protocol extension: thinking output

Post by Greg Strong » Sat Jan 18, 2014 11:25 pm

hgm wrote:Well, I thought it would be better to exclude 100, to exclude that it could be 3 characters. If it is 100, just send 99...

Engines don´t need to always use 100%. Other programs could steal CPU time from them. I guess this is the point of having this info.
OOooooohhh... I was thinking the was the percentage used out of the total CPU allocated to the engine by the OS (which would always be 100), not out of the total. This amounts to asking the OS like Windows Task Manager does, and would be very platform dependent. I think this is a very strange thing to put into an engine - Windows already has Task Manager and PerfMon, and, for that matter, why not just build it into the GUI? The GUI could determine this information for every engine with no help from the engine itself, and the GUI, by nature, is already platform dependent. Personally, I think we should drop this. The fact that UCI supports it isn't a good enough reason IMHO. (How many engines actually bother to add this?)

User avatar
hgm
Posts: 23871
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: WB protocol extension: thinking output

Post by hgm » Sun Jan 19, 2014 2:33 am

Well, getting the time is alsways platform-dependent. In Windows I use GetTickCount(), in Linux that doesn't exist. But in gcc clock() seems to give you CPU time on both platforms. So I could simply print clock()*(1000./CLOCKS_PER_SECOND)/GetTickCount(). So it is not a big deal.

Michel
Posts: 2079
Joined: Sun Sep 28, 2008 11:50 pm

Re: WB protocol extension: thinking output

Post by Michel » Sun Jan 19, 2014 8:39 am

So I could simply print clock()*(1000./CLOCKS_PER_SECOND)/GetTickCount().
I assume that in a multithreaded program this will be > 100 so you would have to divide by the number of cpu's in the system.

User avatar
hgm
Posts: 23871
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: WB protocol extension: thinking output

Post by hgm » Sun Jan 19, 2014 9:02 am

By the number of threads you are using, I would think. Then you have always 99% = healthy, lower = trouble.

Michel
Posts: 2079
Joined: Sun Sep 28, 2008 11:50 pm

Re: WB protocol extension: thinking output

Post by Michel » Sun Jan 19, 2014 9:45 am

By the number of threads you are using, I would think. Then you have always 99% = healthy, lower = trouble.
I agree that looks more convenient (I guess it does not matter which definition you use as long as it is unambiguously fixed in the protocol).

The analogue of gettickount in linux is gettimeofday BTW.

User avatar
Greg Strong
Posts: 388
Joined: Sun Dec 21, 2008 5:57 pm
Location: Washington, DC

Re: WB protocol extension: thinking output

Post by Greg Strong » Sun Jan 19, 2014 5:57 pm

hgm wrote:Well, getting the time is alsways platform-dependent. In Windows I use GetTickCount(), in Linux that doesn't exist. But in gcc clock() seems to give you CPU time on both platforms. So I could simply print clock()*(1000./CLOCKS_PER_SECOND)/GetTickCount(). So it is not a big deal.
So add more platform dependent stuff? What about my point that it makes a lot more sense to put it in the GUI? Write it once and it works for all engines and calculates it the same way.

User avatar
hgm
Posts: 23871
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: WB protocol extension: thinking output

Post by hgm » Sun Jan 19, 2014 6:04 pm

I don't think clock() would be platform dependent.

I also don't know whether the GUI can reliably obtain this information. What the GUI considers 'engines' could in fact be adapters, which spawn the real engine process. Or engines could spawn other threads and processes.

Anyway, I have not added cpuload and hashfull in the specs accompanying the latest development release of XBoard. I only mention knps, seldepth and tbhits, with the remark that more could be added in the future. The Polyglot ShowTbHits option also would only send these three, when switched on. XBoard does already accept 5 extra integers, though, but it would ignore two of them. This will make this version already compatible with future extensions of the format, whatever we decide they will be.

Post Reply