Page 2 of 4

Re: reviving old c# codebase engine, 0x88

Posted: Sat Mar 06, 2021 2:43 am
by spirch
good to know that it's valid, thanks :-)

so i did full kind of perft, no bulk counting of last depth it's about 3.5 millions instead of 87

my thing suck haha

Re: reviving old c# codebase engine, 0x88

Posted: Sat Mar 06, 2021 5:54 am
by spirch
if some of you are interested this is my profiling result of

depth 5 for

Code: Select all

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq -
full perft
Image

perft, bulk counting of last depth
Image

based on this result, i might be doing way too many thing in my full perft, the number are crazy, maybe i got a bad condition in my code that count legal move of depth 6

Re: reviving old c# codebase engine, 0x88

Posted: Sat Mar 06, 2021 6:12 am
by spirch
and this is why you must always profile your app

full perft, proper, same as above, still depth 5
Image

now depth 6

Code: Select all

  A B C D E F G H
1 R N B Q K B N R  Kind of perft: Full Perft, doing all move/undo to the last depth
2 P P P P P P P P  Started 6 depths at 2021-03-06 00:11:17 finished at 2021-03-06 00:11:23
3 ■ ■ ■ ■ ■ ■ ■ ■  FEN: rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq -
4 ■ ■ ■ ■ ■ ■ ■ ■
5 ■ ■ ■ ■ ■ ■ ■ ■  Expected Moves   : 119,060,324
6 ■ ■ ■ ■ ■ ■ ■ ■  Total Moves Done : 119,060,324
7 p p p p p p p p  Time Taken       : 5,656ms
8 r n b q k b n r  Moves per second : 21,050,269
before my fix, it was about 3.5 millions instead of 21

Re: reviving old c# codebase engine, 0x88

Posted: Sat Mar 06, 2021 6:16 pm
by lithander
spirch wrote: Sat Mar 06, 2021 6:12 am before my fix, it was about 3.5 millions instead of 21
What did you fix?

Re: reviving old c# codebase engine, 0x88

Posted: Sun Mar 07, 2021 2:08 am
by spirch
lithander wrote: Sat Mar 06, 2021 6:16 pm
spirch wrote: Sat Mar 06, 2021 6:12 am before my fix, it was about 3.5 millions instead of 21
What did you fix?
if you look at first screenshot, you can see that there is about 81 million call to my pseudo move method but my perft didnt calculated these move

so it mean that after doing perft 5, my code ran the pseudo/legal move on depth 6 and ignoring the result which is bad/wrong

it should have been like my third screenshot, 3.3 millions call

the fix was finding where i had a missing "if" to stop looking up the move above the desired depth and implementing the proper "stop"

Re: reviving old c# codebase engine, 0x88

Posted: Sun Mar 07, 2021 2:26 am
by spirch
lithander wrote: Sat Mar 06, 2021 6:16 pm
spirch wrote: Sat Mar 06, 2021 6:12 am before my fix, it was about 3.5 millions instead of 21
What did you fix?
also, i saw your link in your signature, i don't know if you ever did a profiling run on your engine, here is one with peft 5 8-)

Image

i don't know anything about the code but first thing i would say, remove the recursive call to perft, there is a cost there but you can also look at some hotspot and see if there anything to do there to optimize it

Re: reviving old c# codebase engine, 0x88

Posted: Sun Mar 07, 2021 11:24 am
by mvanthoor
spirch wrote: Sun Mar 07, 2021 2:26 am i don't know anything about the code but first thing i would say, remove the recursive call to perft, there is a cost there but you can also look at some hotspot and see if there anything to do there to optimize it
How would you do perft non-recursively? You could create a move list, and then on move one, generate a new move list and stick it in front of the first one. That way you could go breadth-first instead of depth-first, but that would not be faster. You still have to go through all the moves.

Re: reviving old c# codebase engine, 0x88

Posted: Sun Mar 07, 2021 12:50 pm
by lithander
spirch wrote: Sun Mar 07, 2021 2:26 am also, i saw your link in your signature, i don't know if you ever did a profiling run on your engine, here is one with peft 5 8-)

Image

i don't know anything about the code but first thing i would say, remove the recursive call to perft, there is a cost there but you can also look at some hotspot and see if there anything to do there to optimize it
Thanks for taking the time to look into my code! Much appreciated. What tool are you using for the profiling?

I'm using Visual Studio IDE and of course I did a few profiling runs every now and then. That my perft runs only at 10M Nodes/s is not any fault of the C# language but comes down to a few design decisions motivated by my pledge to write code that's simple and easy to understand.

For example you may notice that CollectMoves takes twice as long as AddMoves. What *else* is it spending time on if not adding moves?? It's scanning the board looking for pieces of the active color. Piece lists could speed this up but other then speeding up the search it doesn't really *add* any value, it just makes things faster and more complicated. Also it would make the board instance "fatter" and I make a *lot* of copies of board instances. (Also visible in your profiler)

Your profiler doesn't add these values up but Consider is actually called on *each* pseudo-legal move to make sure it's legal. How do you make sure of that? You play the move and look if it puts your king in check. That's costly. You have to create a new Board instance (because I also didn't implement Undo for above state reasons) play the Move, scan the board for the king and test if the square he's on is attacked. Once you have that boolean result you let the Garbage Collector mop up the mess because there's a whole board instance created that noone needs anymore. Poor thing.

The garbage collector is good at it though. The process doesn't exceed 18MB of allocated memory. So it's not really a memory leak or anything, it's how C# is supposed to be used. 10M Nodes/s is nothing to brag about, though, and if you care about performance don't do it like me! ;)

When I started I didn't know that the chess programming community would be so competitive about speed. I like it. But I won't try to optimize Minimal Chess retroactively for speed because there *is* a price to be paid for every optimization. It doesn't fit my vision for it. My next chess engine, if I stick with this surprisingly addictive hobby, will be more ambitious in that regard.

Re: reviving old c# codebase engine, 0x88

Posted: Sun Mar 07, 2021 1:03 pm
by mvanthoor
lithander wrote: Sun Mar 07, 2021 12:50 pm When I started I didn't know that the chess programming community would be so competitive about speed. I like it.
It is the logical conclusion: people will add features to their engines, and so many engines will grow towards one another. In the end when engines have the same features, speed is the last bastion technical thing where engines differentiate.
But I won't try to optimize Minimal Chess retroactively for speed because there *is* a price to be paid for every optimization. It doesn't fit my vision for it. My next chess engine, if I stick with this surprisingly addictive hobby, will be more ambitious in that regard.
Optimizations/extra features do make the engine more complicated indeed, because these features are used for speed-up only (caching/storing intermediate stuff, etc...), and not for pure chess playing.

(Read this with Worf's voice): "I didn't write all those PM's for nothing. If you don't stick with this hobby, I'll be... angry."

:lol:

Re: reviving old c# codebase engine, 0x88

Posted: Sun Mar 07, 2021 4:43 pm
by spirch
mvanthoor wrote: Sun Mar 07, 2021 11:24 am
spirch wrote: Sun Mar 07, 2021 2:26 am i don't know anything about the code but first thing i would say, remove the recursive call to perft, there is a cost there but you can also look at some hotspot and see if there anything to do there to optimize it
How would you do perft non-recursively? You could create a move list, and then on move one, generate a new move list and stick it in front of the first one. That way you could go breadth-first instead of depth-first, but that would not be faster. You still have to go through all the moves.
c# and recursion when you look at pure optimization is tricky, I will let you do the search on your preferred online search engine.

by the way, I do kind of what you are saying in my perft :o by memory I did gain some speed when I did it. that is why i kept it, otherwise it would be way much easier to use recursion code, way way more easier

visually this is how my perft work
Image