reviving old c# codebase engine, 0x88

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

spirch
Posts: 95
Joined: Fri Nov 09, 2012 12:36 am

Re: reviving old c# codebase engine, 0x88

Post 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
spirch
Posts: 95
Joined: Fri Nov 09, 2012 12:36 am

Re: reviving old c# codebase engine, 0x88

Post 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
spirch
Posts: 95
Joined: Fri Nov 09, 2012 12:36 am

Re: reviving old c# codebase engine, 0x88

Post 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
User avatar
lithander
Posts: 881
Joined: Sun Dec 27, 2020 2:40 am
Location: Bremen, Germany
Full name: Thomas Jahn

Re: reviving old c# codebase engine, 0x88

Post 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?
Minimal Chess (simple, open source, C#) - Youtube & Github
Leorik (competitive, in active development, C#) - Github & Lichess
spirch
Posts: 95
Joined: Fri Nov 09, 2012 12:36 am

Re: reviving old c# codebase engine, 0x88

Post 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"
spirch
Posts: 95
Joined: Fri Nov 09, 2012 12:36 am

Re: reviving old c# codebase engine, 0x88

Post 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
User avatar
mvanthoor
Posts: 1784
Joined: Wed Jul 03, 2019 4:42 pm
Location: Netherlands
Full name: Marcel Vanthoor

Re: reviving old c# codebase engine, 0x88

Post 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.
Author of Rustic, an engine written in Rust.
Releases | Code | Docs | Progress | CCRL
User avatar
lithander
Posts: 881
Joined: Sun Dec 27, 2020 2:40 am
Location: Bremen, Germany
Full name: Thomas Jahn

Re: reviving old c# codebase engine, 0x88

Post 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.
Minimal Chess (simple, open source, C#) - Youtube & Github
Leorik (competitive, in active development, C#) - Github & Lichess
User avatar
mvanthoor
Posts: 1784
Joined: Wed Jul 03, 2019 4:42 pm
Location: Netherlands
Full name: Marcel Vanthoor

Re: reviving old c# codebase engine, 0x88

Post 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:
Author of Rustic, an engine written in Rust.
Releases | Code | Docs | Progress | CCRL
spirch
Posts: 95
Joined: Fri Nov 09, 2012 12:36 am

Re: reviving old c# codebase engine, 0x88

Post 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