Why C++ instead of C#?

[klx]

FWIW I tend to rely on Intels vTune performance Analyzer when I'm trying to profile individual functions.

Well, then you're doing it wrong. Since this change results in different behavior (TT contents) you can not test it in isolation. What if you have a considerably higher TT collision rate after this change for example. Boom, you just halved your performance, and you didn't even notice it.

Also, you need to close down your Chrome and Spotify since they consume CPU and make the results unreliable.

[R. Tomasi]

FWIW I tend to rely on Intels vTune performance Analyzer when I'm trying to profile individual functions.

Well, then you're doing it wrong. Since this change results in different behavior (TT contents) you can not test it in isolation. What if you have a considerably higher TT collision rate after this change for example. Boom, you just halved your performance, and you didn't even notice it.

Also, you need to close down your Chrome and Spotify since they consume CPU and make the results unreliable.

Full of seasoning again, huh?

[amanjpro]

FWIW I tend to rely on Intels vTune performance Analyzer when I'm trying to profile individual functions.

Well, then you're doing it wrong. Since this change results in different behavior (TT contents) you can not test it in isolation. What if you have a considerably higher TT collision rate after this change for example. Boom, you just halved your performance, and you didn't even notice it.

Also, you need to close down your Chrome and Spotify since they consume CPU and make the results unreliable.

Full of seasoning again, huh?

Did he season himself again?

[mvanthoor]

I converted the engine to assign a TT with a number of entries equal to a power of 2.

Ok thanks for the details but you're talking about a different change now? I thought we were talking about changing division to shifting, while still keeping your non-power-of-two tables.

3 - When both versions have equal memory available, the faster version does gain about 25 Elo.

So this right here tells me that you are most likely NOT testing this correctly. When it comes to pure performance, +25 Elo corresponds to 30% faster overall. There is very little chance that removing a modulo call in the TT probe would make your entire engine 30% faster.

I tried the power of 2 TT first. Maybe I'll try the shift later.

The power of two table _is_ faster, when tested for Time to Depth on a range of positions, but I also wanted to know if that extra speed (about 2-3% in some positions) would translate into some Elo gain. It doesn't. I tested both engines with actual equal memory available, and both with 32 MB set and letting them do their thing. There is no difference.

When I tested this for an Elo-change earlier, I must have done something wrong. The SPRT test says that there's absolutely no difference and it doesn't matter if I make the memory between the engines equal, or if I just set "32 MB" in both (where the power of two TT thus has less memory).

[lithander]

Today I installed Visual Studio 2022 and changed my (unpublished) bitboard perft experiments to target .Net 6 (instead of .Net 5) and was delighted to see a 10% gain in performance just by targeting a newer framework. (45M Nps perft instead of 40M)

...so of course I thought of our little community project here where we tried to make a C# port of the QBB perft routine as fast as possible. In the end the gap between C/C++ and C# was only 10M NPS and so... with another 10% speed boost the gap would have finally been negligible.

But the .Net 6 version of QBB-Perft turned out to lose 8M NPS over the .Net 5 build making it 15% slower. I mean it's great that my own routines gained speed (because those I'm going to use for my future chess programming) but I would have really expected more consistent results here... after all both are bitboard based chess engines running the same perft test?!

What are your experiences with .Net 6 performance? (If you tried it yet...)

P.S.: I used a Ryzen 3600 @ 4.2Ghz on Windows 10

[emadsen]

What are your experiences with .Net 6 performance? (If you tried it yet...)

Upgrading from .NET 5 to .NET 6 did not improve the performance of MadChess at all. However, I haven't played with PGO yet. Microsoft has indicated some PGO features are experimental, disabled by default, and must be enabled by environmental variables. Rather than tweak environmental variables (which I wouldn't expect a user to do), I'll play with PGO once it graduates from an experimental to fully-supported feature.

[dangi12012]

Today I installed Visual Studio 2022 and changed my (unpublished) bitboard perft experiments to target .Net 6 (instead of .Net 5) and was delighted to see a 10% gain in performance just by targeting a newer framework. (45M Nps perft instead of 40M)

...so of course I thought of our little community project here where we tried to make a C# port of the QBB perft routine as fast as possible. In the end the gap between C/C++ and C# was only 10M NPS and so... with another 10% speed boost the gap would have finally been negligible.

But the .Net 6 version of QBB-Perft turned out to lose 8M NPS over the .Net 5 build making it 15% slower. I mean it's great that my own routines gained speed (because those I'm going to use for my future chess programming) but I would have really expected more consistent results here... after all both are bitboard based chess engines running the same perft test?!

What are your experiences with .Net 6 performance? (If you tried it yet...)

P.S.: I used a Ryzen 3600 @ 4.2Ghz on Windows 10

Have you used the [MethodImploptions.AggressiveInlining] yet? It makes a big difference.
Also donet has had the option for ahead of time compilation which could also help in terms of performance.

In theory JIT compiled languages could surpass statically compiled languages in terms of performance - but this hasnt happened yet - and wont in the near future, because these languages have had design choices that have a runtime cost associated with them.
One example would be pointer aliasing which doesnt have a keyword in C++ and if the compiler cant prove that then SIMD is off limits.
With C# and JIT the compiler could "prove" for all known inputs that no overlap exists during runtime and just emit the SIMD code.

Also think about that you cannot ever ever compile with march=native and expect your software to run anywhere else without recompilation. With JIT march=native would be the default behaviour.
Oh what could have been...

[Ras]

One example would be pointer aliasing which doesnt have a keyword in C++

Extern C, restrict, LTO. Then again, actual C++ compilers like GCC and Clang support restrict also in C++ anyway.

[lithander]

Have you used the [MethodImploptions.AggressiveInlining] yet? It makes a big difference.
Also donet has had the option for ahead of time compilation which could also help in terms of performance.

The real surprise (to me) was not that I gained 10% performance in my own perft implementation (not fully optimized yet) but with the quite heavily optimized and profiled https://github.com/lithander/QBB-Perft becoming significantly slower with .Net 6. It uses [MethodImploptions.AggressiveInlining] quite heavily and several people in this thread made contributions to the code.

I didn't dig into it using the profiler but I can say that publishing options (like ready-to-run compilation, single file etc) beyond the targeted framework didn't have any impact on the performance. Only the target framework does have an impact and that one is contradicting my expectations.

But it's not a problem I'm going to spend much more time on. Just a curious observation...

Edit: If I target the "portable" runtime .Net 6 achieves the same performance as .Net 5. Only the win-x64 runtime seems to be slower.

[Tearth]

The real surprise (to me) was not that I gained 10% performance in my own perft implementation (not fully optimized yet) but with the quite heavily optimized and profiled https://github.com/lithander/QBB-Perft becoming significantly slower with .Net 6. It uses [MethodImploptions.AggressiveInlining] quite heavily and several people in this thread made contributions to the code.

Be very careful with [MethodImplOptions.AggressiveInlining] - back in the time when I was writing Cosette, I've learned that overusing this attribute (especially in more complex methods) surprisingly easily leads to pretty significant performance drops. The only explanation for this effect I have is the processor's cache which has to deal with bigger chunks of compiled code reducing any gain from removing method calls.