"SuperLazy SMP" by using move list chunks: would this work?

[mvanthoor]

But how do I do this at depth 2?

- First generate moves at depth 1 and store them in a queue with d=1, giving 20 moves...
- Then generate all moves at depth 2 and store them in the same queue with d=2... giving 400 moves and the original 20.

You don't store the moves in a queue but the resulting positions after you made the moves. So what you sort of doing is a perft2 where you use the leaf positions as the queue for you threads. From the start position you end up with 400 leaf positions from where you do a perft depth - 2.

That makes some more sense indeed. I assume you just keep "20" and "400" as counts for depth 1 and 2 separately, and then add the counts coming from that queue. I'll try it at some time.

Great! A very special moment was when I finally got rofChade to work on my DGT pi with DGT board and got beaten very bad by my own engine. I hope you will get to enjoy that moment soon

I'm sure that, given a half decent evaluation function (I'm starting out with only material counting and PSQT's from this thread: http://www.talkchess.com/forum3/viewtop ... =7&t=50840) and I'll see where it'll end up. Maybe, because Alpha/Beta depends so heavily on it, I'll add a simple move-ordering in the first version. It's able to search up to 5-6 ply already in a few seconds (in perft, single-threaded), so if alpha/beta and move ordering is added and it can search deeper than that, I'm sure this engine will be able to beat me.

I have a DGT Board (two actually), and two Pi 4's.

It is actually the intention to add a level functionality, so I can actually play against it myself.

If the formula Human_Elo = CCRL * 0.7 +840 (which floats around this board) still holds, that functionality would be needed as soon as the engine hits CCRL 1650... which might actually be one of the early versions

[mvanthoor]

Code: Select all

type Depth = usize;
let TARGET_SIZE = 400;
let mut queue: Vec<(GameState, Depth)> = Vec::new();
queue.push((root_node, perft_depth));
while queue.len() < TARGET_SIZE:
	if queue.len() == 0 {break;}
	let (node, depth) = queue.pop();
	assert(depth > 0) //Don't want to think about this case now
	let legal_moves = gen_moves(node);
	for mv in legal_moves{
		queue.push_last((make_move(node, mv), depth -1));
	}

This will fill the queue up until it has reached a certain size, and will leave the "Tasks" with higher depths at the front of the queue, so that they will be dealt with first, which is good since they are the most probable to take the most of time. So IIRC this is just a typical breadth-first schema.

Thanks; yes, this makes it clearer. Now that you mention it, it should indeed be a breath-first search.

- Get the legal moves from the root node, and store them.
- Get the first move from the queue, generate legal moves (for the next ply) and store them at the end of the queue
- Get the next move from the queue, generate legal moves (for the next ply) and store them at the end of the queue
- until you hit the required depth, and then stop storing moves in the queue and finish it to its end.

That would be a breath-first search to a certain depth. It's a very long time ago since I used that scheme somewhere... maybe even as far back as first class in uni

Only, in this case you stop filling the queue after you reach a target size instead of target depth.

[Ronald]

Up to rofChade 1.0 I was only using material and PST for evaluation. It wasn't the intention, but as rofChade became stronger it became a sort of challenge to try to optimize the search. 1.0 reached 2800 in CCRLs blitz rating, much much higher than ever expected with any rofChade (PeSTO, a later version reaches 2980). I think this focus on search helped a lot to reach the current rating.

I'm now experimenting with NNUE and the first results are mindblowing. Nearly 200 elo gain.
The development of our current evaluation function is going on for 70 years now, since Shannon published his amazing article on computer chess. Even with the latest developments around tuning etc., the evaluation is rubbish compared to a "simple" neural net. It looks like our current heuristics used in evaluation functions are wrong/incomplete.

[chrisw]

Up to rofChade 1.0 I was only using material and PST for evaluation. It wasn't the intention, but as rofChade became stronger it became a sort of challenge to try to optimize the search. 1.0 reached 2800 in CCRLs blitz rating, much much higher than ever expected with any rofChade (PeSTO, a later version reaches 2980). I think this focus on search helped a lot to reach the current rating.

I'm now experimenting with NNUE and the first results are mindblowing. Nearly 200 elo gain.
The development of our current evaluation function is going on for 70 years now, since Shannon published his amazing article on computer chess. Even with the latest developments around tuning etc., the evaluation is rubbish compared to a "simple" neural net. It looks like our current heuristics used in evaluation functions are wrong/incomplete.

I was in a minority of one, arguing that in the 1990’s. They said chess was all search and tactics.