My measurements show a 50% overhead of going through UCI. eval takes about 20% of CPU, zurichess about 75% (out of which 20% is to decode the FEN).mar wrote:Yes, it seems very slow as I expected. How many positions?Joerg Oster wrote:I ran findk for both, Zurichess and Stockfish.
Each iteration with Zurichess took about 14 minutes, while Stockfish needed about 4 minutes.
For comparison, my integrated tuner does one iteration (paralellized) in ~15-20 seconds on a quad (~6.5M positions).
I doubt you can use this tuning method without integrating it into the engine (technically you can but you would have wait for very long).
Maybe a custom protocol intead of UCI might work,
because, among other things, sending position fen each time will slow it down further. Doing depth 1 search each time is also overkill.
It's much better to store the unpacked boards/positions in memory.
So all that's needed is to feed the engine with positions first and then run a command that simply does qsearch on each and outputs the final value.
This may work.
I could make txt much faster, but then everybody would need to write a new coding/decoding logic. I want people (like Joerg Oster, for example) to start experimenting with txt on their engines without investing too much time. If they find it useful, writing a custom evaluation function bypassing UCI is very easy (it took me 2h to write the generic one).
Nonetheless, right now I'm trying to get some improvements at least for Zurichess, which I failed so far.