Programming issue: engine speed slowing over time

[Sopel]

you have an algorithm somewhere that has complexity that depends on node count

[Ras]

Are you using for loops on your deep ply searches?

I've never seen an engine that would use 24 nested for loops. Instead, you use recursion. Also, it shouldn't be using much stack in the first place. That points to a lot of superfluous objects that not only cause the general speed issue, but also overload the runtime that has to keep track of that.

[flok]

Could it be that your cpu is overheating and that it then clocks down?

not likely with an HP Envy

Not sure what the brand of a laptop has to do with it. If you google for throtteling you'll see that it is quite normal for a laptop to do this. It's a relatively small device with small fans and a cpu that can produce a lot of heat.

[flok]

If it were an issue with Windows it would also happen to other engines. Have you tried that?

That's a good point HGM and easy to test for chesnut1071.

[dangi12012]

Its 100% not a windows issue. Same as its 100% not a compiler bug. Its everything else and the sun before any of those become true.

If your nps is logarithmically declining it might be simply a measuring bug where you dont reset the clock.

If its a GC or memory issue you can just look in the Profiling tab!

Having a stackframe 26 levels deep can cost a lot of performance for sure. (C# does not do tail recursion elimination whereas clang does)
Maybe you are even recursing over IEnumerable<T> which is a coroutine with an attached statemachine - that could be it.

As a last resort and wanted to mention this to lithander as well:

You can rewrite your alpha-beta as a non-recursive form where you just push/pop your arguments off a Stack<T> and have everything in a while() loop in the same function (so no recursion). https://www.chessprogramming.org/Iterative_Search
In C# this will be much faster as well as having the benefit of being able to read profiling data again (since the hot path will actually be the hot path and not point to itself again)

[Chessnut1071]

Its 100% not a windows issue. Same as its 100% not a compiler bug. Its everything else and the sun before any of those become true.

If your nps is logarithmically declining it might be simply a measuring bug where you dont reset the clock.

If its a GC or memory issue you can just look in the Profiling tab!

Having a stackframe 26 levels deep can cost a lot of performance for sure. (C# does not do tail recursion elimination whereas clang does)
Maybe you are even recursing over IEnumerable<T> which is a coroutine with an attached statemachine - that could be it.

As a last resort and wanted to mention this to lithander as well:

You can rewrite your alpha-beta as a non-recursive form where you just push/pop your arguments off a Stack<T> and have everything in a while() loop in the same function (so no recursion). https://www.chessprogramming.org/Iterative_Search
In C# this will be much faster as well as having the benefit of being able to read profiling data again (since the hot path will actually be the hot path and not point to itself again)

Thx. You seem to be the most helpful so far. Here's the data for 14-ply and 18-ply. Keep in mind I'm using nested for loops for each ply.

14-ply legal engine calls
time/sec Nodes nodes/sec
88.3 16,931,206 191,746
209.0 48,713,379 233,056
259.0 60,857,278 234,993
316.4 74,742,380 236,265
378.7 89,610,999 236,625
399.6 94,887,657 237,442
442.0 105,097,876 237,805
495.3 117,531,090 237,290
579.6 138,449,795 238,875
614.8 147,309,991 239,624
661.5 158,378,945 239,438
695.6 167,103,915 240,237
738.7 177,782,400 240,679
794.7 191,505,841 240,974 solution

18-ply
time/sec Nodes calls/sec
82.61 20907089 253,082
20.025 25771923 242,938
32.05 33626751 245,080
54.415 46699293 240,238
57.14 60322776 238,423
48.975 72000961 238,452 Hangs

20-ply hangs

First, why aren't 16-plys and under effected? No degradation at all under 18-ply. Everything appears to constant until 18-ply 72,000,000 nodes visited.

Theory: it appears to be related to the garbage collector with Gen 2 and Gen 3 issues. I can't understand why because the large array, my Zobirst Hash 360,000,000 bytes should always be in memory and not swapped out. None of my other arrays are over 85KB.

Are all of you using reclusion instead of for loops? Is so, why don't you have the same problem? I didn't find reclusive calls to be faster than for loops, although some suggested here otherwise.

FENs for the issue above.
18-ply: FEN[211] = "6rk/1p1R3p/2n3p1/p7/8/P3Q3/1qP2PPP/4R1K1 w - - 0 1"; // Parekh Abhishek 9-move mate 1.Qh6
14-ply: FEN[201] = "5k2/ppp2r1p/2p2ppP/8/2Q5/2P1bN2/PP4P1/1K1R4 w - - 0 1 "; // Unknown author 7-move mate [Qe4]

So far there 3 computer jocks looking at it and each one has a different reason. ?>}&&%$!

[dangi12012]

20-ply hangs

First, why aren't 16-plys and under effected? No degradation at all under 18-ply. Everything appears to constant until 18-ply 72,000,000 nodes visited.

If you send me the source I could take a look.
daniel.infuehr@live.de

[Chessnut1071]

20-ply hangs

First, why aren't 16-plys and under effected? No degradation at all under 18-ply. Everything appears to constant until 18-ply 72,000,000 nodes visited.

If you send me the source I could take a look.
daniel.infuehr@live.de

Thx for the offer, but, I think I found a way to isolate the issue. I ran my magic bitboard engine on the same problem and it found the solution using the same arrays and methods used in my PEXT version which is having the issue. There must be something different between the two so I hope it’s a program error rather than a Garbage Collection issue. As soon as the wife gets off my computer-playing solitaire on my machine- I’m going to test them side by side.

Btw, are you using recursive calls instead of nested for loops? Is so, are they really that much of an improvement. It’s not the for loops causing my problem because the magic bitboard engine uses them too.

[flok]

Its 100% not a windows issue. Same as its 100% not a compiler bug. Its everything else and the sun before any of those become true.

How do you know that?

[Hai]

[quote=flok post_id=929250 time=1656656854 user_id=10633]
[quote=dangi12012 post_id=929222 time=1656615999 user_id=12507]
Its 100% not a windows issue. Same as its 100% not a compiler bug. Its everything else and the sun before any of those become true.
[/quote]

How do you know that?
[/quote]

That’s simple.
Its 100% not a windows issue because I’m using a macbook.