Half-year ago I did a small text about writing chess engines in C# and performance issues related to it, where I presented a few interesting methods of optimizing the engine. Today, I want to extend it a bit by new elements, some of them related to the lastly released .NET 5 - they aren’t game-changers, but can nicely improve some parts of code.
Last month was quite busy - I’ve started a new project called Cosette, which is a brand new chess engine written in C# for .NET Core platform. It’s not my first project of this kind (a few years ago I made Proxima b 2.0 (C#), together with even older Proxima b (C++)), so using the gained experience I can finally write a few words about performance tips and tricks, especially in C# language.
Swapping values is probably one of the simplest algorithms which can be imagined - we learn about it when starting our programming story. There are two popular ways to accomplish this: using a temporary variable and XORing (with some restrictions). In the newest C# versions there is also a third way, about which you can read in this article.
Random class is one of the most used parts of the .NET library, which contains a few methods to generate pseudo-random numbers. They are extremely simple to use, but even with this, there are still some traps waiting for a programmer. In this article, I will focus on differences in implementation of this class between .NET Framework and .NET Core, especially seed generation which sometimes leads to interesting bugs.
Closure is a very important concept related to anonymous functions and lambdas. They allow a programmer to use local variables of the parent method inside a body of the inline function and then execute it at any time. The question is, how the C# compiler saves these local variables and how are they restored later - let’s check it.
In the previous article, we talked a bit about hash codes and how they are implemented for reference types - it turned out that it’s just a simple multiplication of thread ID and a random number. Today, we will do the same thing for value types, which are far more complex due to their representation in memory. In the end, I will show a small benchmark to prove that every struct defined by the programmer should override GetHashCode method. Time to dig into CLR source code!