WB protocol extension: thinking output

[Greg Strong]

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

[hgm]

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]

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.

[hgm]

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

[Michel]

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.

[Greg Strong]

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.

[hgm]

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.