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

Discussion of chess software programming and technical issues.

Moderators: Harvey Williamson, Dann Corbit, hgm

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
mvanthoor
Posts: 560
Joined: Wed Jul 03, 2019 2:42 pm
Full name: Marcel Vanthoor

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

Ronald wrote:
Wed Sep 23, 2020 7:29 pm
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
Posts: 560
Joined: Wed Jul 03, 2019 2:42 pm
Full name: Marcel Vanthoor

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

fabianVDW wrote:
Wed Sep 23, 2020 7:35 pm

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();
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
Posts: 112
Joined: Tue Jan 23, 2018 9:18 am
Location: Rotterdam
Full name: Ronald Friederich
Contact:

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

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
Posts: 3851
Joined: Tue Apr 03, 2012 2:28 pm

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

Ronald wrote:
Wed Sep 23, 2020 8:17 pm
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.