C# Performance

[Richard Allbert]

Making the MoveList static didn't make a difference, which is good for the future

[RoadWarrior]

I took a quick look at your code. It seems to have a hard-coded reference to a perft testing folder on the C:\ drive?

[Richard Allbert]

Ah yes, laziness.

I'll load up another verison that just does perft on the standard position I use, and doesn't try to load a missing file

Btw, I added position hashing, and fell back from 4000knps to 3000knps. According to the profiler the Hashing takes 17%, niot sure where the other 8% has come from.

Use the same link for the lastest source

Thanks

Richard

[RoadWarrior]

I've just run your latest code on my primary dev machine - which appears to be significantly faster than your test machine. On a straight run of your original code, I see 7,123 knps for perft 4.

Then I made a couple of changes to your code. First I moved the stopwatch stop/start to just before and after the StartPerft call. Then I changed the FEN to use the initial position. Now doing perft 5, I see 7,143 knps. On perft 6, I see 7,470 knps. And this includes the Zobrist hashing, which I don't do.

IMO, that speed is good enough as a starting point. Obviously this can be optimised later, but it might be good to start working on the evaluation function as a change from performance tuning.

[Richard Allbert]

Hi Mark,

that's a lot faster than here - I used once core of a core 2 duo 2.5Ghz.

Are there any special compiler settings you used?

Regarding the performance, it is still less than 50% the speed of a similar structured C program I have.

Next step is either skeleton Evaluation, which I'd like to build up with tuning ( which takes a lot of time), or the hash table.

The hash table seems like an interesting step, as that can also be debugged with the perft.

I hope there isn't too much of a hit with the hash table implementation - in C you can just assign a pointer to a block of memory, easily resizable. It will be interesting to see how the CLR handles something similar.

Richard

[lucasart]

The hash table seems like an interesting step, as that can also be debugged with the perft.

The only thing that perft will be able to debug here is hash collisions: different positions having the same hash key. But if your implementation of zobrist keys isn't crappy, that will be so rare, that you might spend your whole life running perft debugging and will never find a hash collision.

Hash table leads to errors when it is incorrectly used in the search, and there are many pitfalls...

PS: whatever you do, never use the random generator of C#. All known programming languages' random generator are flawed, and some are *severly* flawed. The best RNG these days are the KISS family. Also for portability, as a different implementation of C# will most likely have a different RNG.

[Richard Allbert]

Hi Lucas,

I'll take a look at the random number generator.

With the perft I can do some hash debugging - instead of storing move /score I store move / nodes, and use hash hits to count nodes.

The perft with hash should give the same nodes as without. If this is the case, I can safely assume storing, probing is working ok.

[RoadWarrior]

It looks like I use the same compiler optimisation settings (for a release build) as you.

See my blog entry here [1] for a.NET Framework class that will give you cryptographically-secure pseudo-random numbers in C#. This will be more than adequate, as long as you avoid modulo bias using the technique mentioned in the article.

[1] http://sleeksoft.co.uk/public/techblog/ ... 316_1.html

[Richard Allbert]

Thanks Mark.

Nice article, I'll have to look at the others in the series as well.

Richard

[Ron Murawski]

PS: whatever you do, never use the random generator of C#. All known programming languages' random generator are flawed, and some are *severly* flawed.

Pseudo-random number generation provided by languages has improved markedly. Your statement about flaws was once true (for instance: C's infamous RANDU function), but this problem is mostly solved. Quite a few languages use MersenneTwister and that's just one of the many strong generators that are available.

The best RNG these days are the KISS family.

'Best' is a slippery word. If I wanted a cryptographically secure PRNG I wouldn't use KISS, I would use something stronger. But, if I wanted to bang out good PRNs as quickly as possible, then KISS would be a good choice. Keep in mind that MersenneTwister would also be a very good choice.