Very Lazy SMP and worker threads

[chrisw]

I been playing with first shot idea over and above full-on Lazy SMP (main thread reports UCI, time controls etc, workers just search only and make writes to global hash).

Idea 1. Track and save PV, eval, bound in the worker threads, and then, on timeout, check to see if any worker searched either deeper than main thread, or generated a different root best move with better eval.

So far, it hasn't dropped into any of my breakpoints set to catch that.
Does this make sense? No worker with different better move?

6 cores, 4 threads,10 seconds search time (albeit in slower debug mode)

[Joost Buijs]

I been playing with first shot idea over and above full-on Lazy SMP (main thread reports UCI, time controls etc, workers just search only and make writes to global hash).

Idea 1. Track and save PV, eval, bound in the worker threads, and then, on timeout, check to see if any worker searched either deeper than main thread, or generated a different root best move with better eval.

So far, it hasn't dropped into any of my breakpoints set to catch that.
Does this make sense? No worker with different better move?

6 cores, 4 threads,10 seconds search time (albeit in slower debug mode)

This is what I also do, at the end of the search I check all the threads to see if there is a better combination of score, depth and move. With the shared hash-table it does not happen very often, but occasionally a slave thread finds a different move with a better score or depth. I only show the PV from the master thread, it would not be worthwhile to fix this.

Code: Select all

		// try to find the thread with the best results
		move_t best_move = Search[0].m_bestmove;
		int best_depth = Search[0].i_bestdepth;
		int best_score = Search[0].i_bestscore;

		for (int tn = 1; tn < actualThreads; tn++)
		{
			if ((Search[tn].i_bestscore > best_score && Search[tn].i_bestdepth >= best_depth)
				|| (Search[tn].i_bestscore == best_score && Search[tn].i_bestdepth > best_depth))
			{
				best_depth = Search[tn].i_bestdepth;
				best_score = Search[tn].i_bestscore;
				best_move = Search[tn].m_bestmove;
			}
		}

[chrisw]

I been playing with first shot idea over and above full-on Lazy SMP (main thread reports UCI, time controls etc, workers just search only and make writes to global hash).

Idea 1. Track and save PV, eval, bound in the worker threads, and then, on timeout, check to see if any worker searched either deeper than main thread, or generated a different root best move with better eval.

So far, it hasn't dropped into any of my breakpoints set to catch that.
Does this make sense? No worker with different better move?

6 cores, 4 threads,10 seconds search time (albeit in slower debug mode)

This is what I also do, at the end of the search I check all the threads to see if there is a better combination of score, depth and move. With the shared hash-table it does not happen very often, but occasionally a slave thread finds a different move with a better score or depth. I only show the PV from the master thread, it would not be worthwhile to fix this.

Thanks. Scrap my earlier not finding anything better in the workers, that was a bug. Now it finds, both deeper and different moves. Can't report on how often, maybe 20% of positions, very roughly.

I figured it was necessary to swap in the PV s well, before outputting the different BESTMOVE. Some of the gui's check the PV and use PV[0] as best (I think). Soem may also check off PV[0] against BESTMOVE, not sure.

UCI spec rather implies that info (PV, etc) should match 'bestmove' and egt sent before it, which is why I interpolated the threads UCI string, beforehand (if bestmove changes)

* bestmove [ ponder ]
the engine has stopped searching and found the move best in this position.
the engine can send the move it likes to ponder on. The engine must not start pondering automatically.
this command must always be sent if the engine stops searching, also in pondering mode if there is a
"stop" command, so for every "go" command a "bestmove" command is needed!
Directly before that the engine should send a final "info" command with the final search information,
the the GUI has the complete statistics about the last search.

Dunno? Not sure.

[chrisw]

I been playing with first shot idea over and above full-on Lazy SMP (main thread reports UCI, time controls etc, workers just search only and make writes to global hash).

Idea 1. Track and save PV, eval, bound in the worker threads, and then, on timeout, check to see if any worker searched either deeper than main thread, or generated a different root best move with better eval.

So far, it hasn't dropped into any of my breakpoints set to catch that.
Does this make sense? No worker with different better move?

6 cores, 4 threads,10 seconds search time (albeit in slower debug mode)

This is what I also do, at the end of the search I check all the threads to see if there is a better combination of score, depth and move. With the shared hash-table it does not happen very often, but occasionally a slave thread finds a different move with a better score or depth. I only show the PV from the master thread, it would not be worthwhile to fix this.

Thanks. Scrap my earlier not finding anything better in the workers, that was a bug. Now it finds, both deeper and different moves. Can't report on how often, maybe 20% of positions, very roughly.

I figured it was necessary to swap in the PV s well, before outputting the different BESTMOVE. Some of the gui's check the PV and use PV[0] as best (I think). Soem may also check off PV[0] against BESTMOVE, not sure.

UCI spec rather implies that info (PV, etc) should match 'bestmove' and egt sent before it, which is why I interpolated the threads UCI string, beforehand (if bestmove changes)

* bestmove [ ponder ]
the engine has stopped searching and found the move best in this position.
the engine can send the move it likes to ponder on. The engine must not start pondering automatically.
this command must always be sent if the engine stops searching, also in pondering mode if there is a
"stop" command, so for every "go" command a "bestmove" command is needed!
Directly before that the engine should send a final "info" command with the final search information,
the the GUI has the complete statistics about the last search.

Dunno? Not sure.

Edit: ok, now to see if any effect on Elo .....

[Joost Buijs]

I figured it was necessary to swap in the PV s well, before outputting the different BESTMOVE. Some of the gui's check the PV and use PV[0] as best (I think). Soem may also check off PV[0] against BESTMOVE, not sure.

UCI spec rather implies that info (PV, etc) should match 'bestmove' and egt sent before it, which is why I interpolated the threads UCI string, beforehand (if bestmove changes)

I know some GUI's seem to use the rootmove from the PV string (Arena ?), IMHO this is not in compliance with the UCI specs. I only use Winboard and it does not seem to have a problem with it, it always seems to play the bestmove I send it, at least I think it does.

[Terje]

SF has threads vote on the best move iirc.

[Joost Buijs]

SF has threads vote on the best move iirc.

Probably there are many engines doing something like this because it seems logical. Unfortunately it doesn't seem to give much additional playing-strength, if any.

[chrisw]

SF has threads vote on the best move iirc.

Probably there are many engines doing something like this because it seems logical. Unfortunately it doesn't seem to give much additional playing-strength, if any.

My first shot is 105:143;199 46% ongoing, negative result so far. Which is a bit disconcerting, but only 500-ish games, so.

Maybe a bug in the testing setup, not sure, difficult to believe substituting in a 'better' move is negative