S_P_A_R_T wrote:

After some review, it looks like I found the root issue of poor S3 performance! You see, after every move, WD updates the progress bar, on TW, this doesn't affect performance much but on S3, it's the difference between 18 NPS, and 136 NPS! (136 / 18 = 7.5x faster!)

Now the only problem is that the progress bar doesn't load along with the engine as it's in search.

ArnoHu wrote:

S_P_A_R_T wrote:

After some review, it looks like I found the root issue of poor S3 performance! You see, after every move, WD updates the progress bar, on TW, this doesn't affect performance much but on S3, it's the difference between 18 NPS, and 136 NPS! (136 / 18 = 7.5x faster!)

Now the only problem is that the progress bar doesn't load along with the engine as it's in search.

Good news! If you want to trigger a screen update from a run-without-refresh custom block, the only way is to broadcast a message and repaint in message receiver. That is by using broadcast, not broadcast-and-wait (the latter will kill performance completely).

S_P_A_R_T wrote:

ArnoHu wrote:

S_P_A_R_T wrote:

After some review, it looks like I found the root issue of poor S3 performance! You see, after every move, WD updates the progress bar, on TW, this doesn't affect performance much but on S3, it's the difference between 18 NPS, and 136 NPS! (136 / 18 = 7.5x faster!)

Now the only problem is that the progress bar doesn't load along with the engine as it's in search.

Good news! If you want to trigger a screen update from a run-without-refresh custom block, the only way is to broadcast a message and repaint in message receiver. That is by using broadcast, not broadcast-and-wait (the latter will kill performance completely).

Oh I see!

But when I try to implement it without “wait”, it just doesn't trigger the screen update… (And doesn't GoK use a broadcast-and-wait in it's code too?)

ArnoHu wrote:

S_P_A_R_T wrote:

ArnoHu wrote:

S_P_A_R_T wrote:

After some review, it looks like I found the root issue of poor S3 performance! You see, after every move, WD updates the progress bar, on TW, this doesn't affect performance much but on S3, it's the difference between 18 NPS, and 136 NPS! (136 / 18 = 7.5x faster!)

Now the only problem is that the progress bar doesn't load along with the engine as it's in search.

Good news! If you want to trigger a screen update from a run-without-refresh custom block, the only way is to broadcast a message and repaint in message receiver. That is by using broadcast, not broadcast-and-wait (the latter will kill performance completely).

Oh I see!

But when I try to implement it without “wait”, it just doesn't trigger the screen update… (And doesn't GoK use a broadcast-and-wait in it's code too?)

Yes it does, but not when the engine is running via run-without-screen-refresh.

Here is the code for progress bar update (wait(0) required for yielding):
https://github.com/ArnoHue/scratch/blob/116a8e6f96294e5f35c313419483e6f7b9bd2141/chess/Engine.scratch#L7567
https://github.com/ArnoHue/scratch/blob/116a8e6f96294e5f35c313419483e6f7b9bd2141/chess/Engine.scratch#L646
https://github.com/ArnoHue/scratch/blob/116a8e6f96294e5f35c313419483e6f7b9bd2141/chess/ProgressBar.scratch#L84

WD (P2) played great against GoK (Medium, black) on Scratch 3 here, and was ahead during early midgame:
https://lichess.org/eSguZ1fM#104

S_P_A_R_T wrote:

ArnoHu wrote:

S_P_A_R_T wrote:

ArnoHu wrote:

S_P_A_R_T wrote:

After some review, it looks like I found the root issue of poor S3 performance! You see, after every move, WD updates the progress bar, on TW, this doesn't affect performance much but on S3, it's the difference between 18 NPS, and 136 NPS! (136 / 18 = 7.5x faster!)

Now the only problem is that the progress bar doesn't load along with the engine as it's in search.

Good news! If you want to trigger a screen update from a run-without-refresh custom block, the only way is to broadcast a message and repaint in message receiver. That is by using broadcast, not broadcast-and-wait (the latter will kill performance completely).

Oh I see!

But when I try to implement it without “wait”, it just doesn't trigger the screen update… (And doesn't GoK use a broadcast-and-wait in it's code too?)

Yes it does, but not when the engine is running via run-without-screen-refresh.

Here is the code for progress bar update (wait(0) required for yielding):
https://github.com/ArnoHue/scratch/blob/116a8e6f96294e5f35c313419483e6f7b9bd2141/chess/Engine.scratch#L7567
https://github.com/ArnoHue/scratch/blob/116a8e6f96294e5f35c313419483e6f7b9bd2141/chess/Engine.scratch#L646
https://github.com/ArnoHue/scratch/blob/116a8e6f96294e5f35c313419483e6f7b9bd2141/chess/ProgressBar.scratch#L84

WD (P2) played great against GoK (Medium, black) on Scratch 3 here, and was ahead during early midgame:
https://lichess.org/eSguZ1fM#104

Ah ok, so the “internal” broadcast isn't with “wait” as that would affect performance, but it's OK for the broadcast that the internal one triggers, as that's not part of the loop, right?

ArnoHu wrote:

S_P_A_R_T wrote:

ArnoHu wrote:

S_P_A_R_T wrote:

ArnoHu wrote:

S_P_A_R_T wrote:

After some review, it looks like I found the root issue of poor S3 performance! You see, after every move, WD updates the progress bar, on TW, this doesn't affect performance much but on S3, it's the difference between 18 NPS, and 136 NPS! (136 / 18 = 7.5x faster!)

Now the only problem is that the progress bar doesn't load along with the engine as it's in search.

Good news! If you want to trigger a screen update from a run-without-refresh custom block, the only way is to broadcast a message and repaint in message receiver. That is by using broadcast, not broadcast-and-wait (the latter will kill performance completely).

Oh I see!

But when I try to implement it without “wait”, it just doesn't trigger the screen update… (And doesn't GoK use a broadcast-and-wait in it's code too?)

Yes it does, but not when the engine is running via run-without-screen-refresh.

Here is the code for progress bar update (wait(0) required for yielding):
https://github.com/ArnoHue/scratch/blob/116a8e6f96294e5f35c313419483e6f7b9bd2141/chess/Engine.scratch#L7567
https://github.com/ArnoHue/scratch/blob/116a8e6f96294e5f35c313419483e6f7b9bd2141/chess/Engine.scratch#L646
https://github.com/ArnoHue/scratch/blob/116a8e6f96294e5f35c313419483e6f7b9bd2141/chess/ProgressBar.scratch#L84

WD (P2) played great against GoK (Medium, black) on Scratch 3 here, and was ahead during early midgame:
https://lichess.org/eSguZ1fM#104

Ah ok, so the “internal” broadcast isn't with “wait” as that would affect performance, but it's OK for the broadcast that the internal one triggers, as that's not part of the loop, right?

Exactly!

S_P_A_R_T wrote:

ArnoHu wrote:

S_P_A_R_T wrote:

ArnoHu wrote:

S_P_A_R_T wrote:

ArnoHu wrote:

S_P_A_R_T wrote:

After some review, it looks like I found the root issue of poor S3 performance! You see, after every move, WD updates the progress bar, on TW, this doesn't affect performance much but on S3, it's the difference between 18 NPS, and 136 NPS! (136 / 18 = 7.5x faster!)

Now the only problem is that the progress bar doesn't load along with the engine as it's in search.

Good news! If you want to trigger a screen update from a run-without-refresh custom block, the only way is to broadcast a message and repaint in message receiver. That is by using broadcast, not broadcast-and-wait (the latter will kill performance completely).

Oh I see!

But when I try to implement it without “wait”, it just doesn't trigger the screen update… (And doesn't GoK use a broadcast-and-wait in it's code too?)

Yes it does, but not when the engine is running via run-without-screen-refresh.

Here is the code for progress bar update (wait(0) required for yielding):
https://github.com/ArnoHue/scratch/blob/116a8e6f96294e5f35c313419483e6f7b9bd2141/chess/Engine.scratch#L7567
https://github.com/ArnoHue/scratch/blob/116a8e6f96294e5f35c313419483e6f7b9bd2141/chess/Engine.scratch#L646
https://github.com/ArnoHue/scratch/blob/116a8e6f96294e5f35c313419483e6f7b9bd2141/chess/ProgressBar.scratch#L84

WD (P2) played great against GoK (Medium, black) on Scratch 3 here, and was ahead during early midgame:
https://lichess.org/eSguZ1fM#104

Ah ok, so the “internal” broadcast isn't with “wait” as that would affect performance, but it's OK for the broadcast that the internal one triggers, as that's not part of the loop, right?

Exactly!

Wait, I've realised that it doesn't refresh until the ply is finished. Is this expected behavior?

S_P_A_R_T wrote:

White Dove v7.06 Has Been Released!

After fixing the progression & eval bars, WD v7.06 improved the S3 performance massively!

https://scratch.mit.edu/projects/858052938/

birdracerthree wrote:

S_P_A_R_T wrote:

White Dove v7.06 Has Been Released!

After fixing the progression & eval bars, WD v7.06 improved the S3 performance massively!

https://scratch.mit.edu/projects/858052938/

White Dove is scary fast on S3 runtime! Why is the NPS so low on Scratch and Turbowarp?

I’ll work on stalemate detection relatively soon. I was going to remove mat evaluations, but I don’t think that’s an option. It looks like a virtual king captured is cut off by a non-mate evaluation somehow. I’m clueless…

There are cat blocks on Turbowarp now

S_P_A_R_T wrote:

birdracerthree wrote:

S_P_A_R_T wrote:

White Dove v7.06 Has Been Released!

After fixing the progression & eval bars, WD v7.06 improved the S3 performance massively!

https://scratch.mit.edu/projects/858052938/

White Dove is scary fast on S3 runtime! Why is the NPS so low on Scratch and Turbowarp?

I’ll work on stalemate detection relatively soon. I was going to remove mat evaluations, but I don’t think that’s an option. It looks like a virtual king captured is cut off by a non-mate evaluation somehow. I’m clueless…

There are cat blocks on Turbowarp now

Although I'm not 100% sure why WD is so slow NPS-wise (it gets like 14k NPS on the starting board with d3 as black, and keep in mind WD considers q-search nodes in this count!), but I have a feeling it's with how I'm implementing legal move generation. As every time full legal moves are generated, it's actually doing 2 pseudo-legal move gens.

And according to the profiler, the actual logic of the legality check is only 10% total, wheras the other 40-50% is the pseudo-legal move gen. This means that if only one set of pseudo-legal move gens was used, you can expect to nearly double performance (NPS-wise).

Overall, the depth WD gets (ply 7-9 during middlegame) is only because of the LMR and NMP, which thankfully, don't seem to be have super negative influence of performance.

ArnoHu wrote:

S_P_A_R_T wrote:

birdracerthree wrote:

S_P_A_R_T wrote:

White Dove v7.06 Has Been Released!

After fixing the progression & eval bars, WD v7.06 improved the S3 performance massively!

https://scratch.mit.edu/projects/858052938/

White Dove is scary fast on S3 runtime! Why is the NPS so low on Scratch and Turbowarp?

I’ll work on stalemate detection relatively soon. I was going to remove mat evaluations, but I don’t think that’s an option. It looks like a virtual king captured is cut off by a non-mate evaluation somehow. I’m clueless…

There are cat blocks on Turbowarp now

Although I'm not 100% sure why WD is so slow NPS-wise (it gets like 14k NPS on the starting board with d3 as black, and keep in mind WD considers q-search nodes in this count!), but I have a feeling it's with how I'm implementing legal move generation. As every time full legal moves are generated, it's actually doing 2 pseudo-legal move gens.

And according to the profiler, the actual logic of the legality check is only 10% total, wheras the other 40-50% is the pseudo-legal move gen. This means that if only one set of pseudo-legal move gens was used, you can expect to nearly double performance (NPS-wise).

Overall, the depth WD gets (ply 7-9 during middlegame) is only because of the LMR and NMP, which thankfully, don't seem to be have super negative influence of performance.

Wow, what a performance improvement on S3, congrats - and it was there the whole time, just the progress bar slowed it done?!

It runs at the same search depth as GoK now on S3, and IMHO is just a question of time until it will win games. Here is one, against GoK (Medium, white), WD was even until move 21, then it started blundering: https://lichess.org/WPMXBRA3#59

For GoK to stay ahead, I am afraid I might have to sacrifice some nice but runtime-intense features, like q-search check sequences, some types of search extensions that might have spectacular results, but that only seldomly, and always cost time, and even some evaluation features, to regain the advantage on search depth, which is more essential for winning in this mode.

S_P_A_R_T wrote:

While doing some research for faster move gen, I came across this engine!

https://maksimkorzh.github.io/wukongJS/wukong.html

Wukong is a mailbox engine (so similar to Scratch chess engines as we don't have access to bitboards) and it has some really cool features!

HasiLover_Test wrote:

Scurious 2.1 just Drew Element 5+8!!! https://lichess.org/zaloM9Gg#97 Scurious 2.1 was black.