But in 1 year or so there will be updates for VS2022 and VS2019 wont get the newest compiler updates anymore.
Also I am old enought to remeber they switched from colored icons in vs2010 to monochrome (which is horrible) icons. It took the whole decade until 2022 that they are all back to colored - and the monochrome is gone thankfully. Its like windows that switches between rounded and square corners every decade or so.
Any ideas on how to get BitScanForward working on VS C# 2022? I included System.Numerics in the assembly list; however, I can't seem to get it working and have to rely on a 64 iteration loop which is slow. I think 2022 is Net 7 which I thought included BSF.
You have BSF!
Just use .net core and System.Runtime.Intrinsics.X86.Bmi1.X64.TrailingZeroCount(value);
I get the message not available on 7.3, use 9.0 or higher. Are you using VS 2022?
I have been using that instruction since VS 2015.
Are you using .net core? .net 5? or are you using .net framework 4.8?
Use .net 5 since that is the current best pick and compatible with the future too.
dangi12012 wrote: ↑Mon Dec 06, 2021 2:39 am
I have been using that instruction since VS 2015.
Are you using .net core? .net 5? or are you using .net framework 4.8?
Use .net 5 since that is the current best pick and compatible with the future too.
.NET 5 will only have support for another 5 months.
Go for .NET 6, which is both LTS and the latest and fastest .NET version, if you get to choose. And if you're using Visual Studio, .NET 6 is only supported by VS2022 and not previous versions.
Today I downloaded MSVC 2022 and enabled the clang option. I wrote a little first program just to see if it will work for me. It ran just fine despite the compiler giving 3 diagnostic errors. I really don't want my code littered with false errors. I'm wondering just how many of these type idiosyncrasies there would be in a fully developed chess engine? However, from what I've seen it appears that clang produces faster executables. And that would be compelling if it were not for non chess engine examples running just slightly slower than standard MSVC in many cases. But, also Mar (and I think Gerd) said that clang understands my SISSY bitboard code much better than other top compilers which can make a sizeable difference in n/s. When Bricabrac was compiled with clang there were 1193 actual errors and it would not compile. So where does this leave me? idk, please help!
Side note: In MSVC 2019 I had to turn off Whole Program Optimization because every so many games it would flake out and become buggy. In MSVC 2022 Whole Program Optimization works just fine.
Mike Sherwin wrote: ↑Tue Dec 07, 2021 4:52 am
Today I downloaded MSVC 2022 and enabled the clang option. I wrote a little first program just to see if it will work for me. It ran just fine despite the compiler giving 3 diagnostic errors. I really don't want my code littered with false errors. I'm wondering just how many of these type idiosyncrasies there would be in a fully developed chess engine? However, from what I've seen it appears that clang produces faster executables. And that would be compelling if it were not for non chess engine examples running just slightly slower than standard MSVC in many cases. But, also Mar (and I think Gerd) said that clang understands my SISSY bitboard code much better than other top compilers which can make a sizeable difference in n/s. When Bricabrac was compiled with clang there were 1193 actual errors and it would not compile. So where does this leave me? idk, please help!
Side note: In MSVC 2019 I had to turn off Whole Program Optimization because every so many games it would flake out and become buggy. In MSVC 2022 Whole Program Optimization works just fine.
For runtime:
I had the experience that MSVC and CLANG produce almost the same speed software. But in other cases clang seems to be a bit faster. Both are better than gcc most of the time in terms of produced binary.
For compiletime:
MSVC has some insane template optimisations. I have a program that needs 10mins to compile with gcc and clang but msvc can do it in 30s. So there is something quadratic vs linear going on with the compiler/linker.
My recommendation:
For debugging and developing in Visual Studio stick with MSVC. It will work and be a good debugging experience.
When you have a finished C++ project you can test out all different compilers and see what settings with which compiler are fastest.
Oh and always try to stick to the standard. Compiler extentions are only that because you get stuck with one compiler and its not portable anymore.
Mike Sherwin wrote: ↑Tue Dec 07, 2021 4:52 am
I'm wondering just how many of these type idiosyncrasies there would be in a fully developed chess engine?
Why would you get type errors? I've compiled many engines with both Clang and GCC (on Linux) without getting any errors or warnings.
When Bricabrac was compiled with clang there were 1193 actual errors and it would not compile. So where does this leave me? idk, please help!
Mike Sherwin wrote: ↑Tue Dec 07, 2021 4:52 amI really don't want my code littered with false errors.
Given that you also experience problems with whole program optimisation, you probably have undefined behaviour in your code, i.e. actual bugs through violating the language standard. C/C++ let you compile code with undefined behaviour, but it just may not do what's intended. That's exactly what compiler warnings are for, as help for the developer. I always compile with -Wall -Wextra and even -Werror so that any warnings are treated like errors, and the program won't build.
Mike Sherwin wrote: ↑Tue Dec 07, 2021 4:52 am
Today I downloaded MSVC 2022 and enabled the clang option. I wrote a little first program just to see if it will work for me. It ran just fine despite the compiler giving 3 diagnostic errors. I really don't want my code littered with false errors. I'm wondering just how many of these type idiosyncrasies there would be in a fully developed chess engine? However, from what I've seen it appears that clang produces faster executables. And that would be compelling if it were not for non chess engine examples running just slightly slower than standard MSVC in many cases. But, also Mar (and I think Gerd) said that clang understands my SISSY bitboard code much better than other top compilers which can make a sizeable difference in n/s. When Bricabrac was compiled with clang there were 1193 actual errors and it would not compile. So where does this leave me? idk, please help!
Side note: In MSVC 2019 I had to turn off Whole Program Optimization because every so many games it would flake out and become buggy. In MSVC 2022 Whole Program Optimization works just fine.
I also tried VS2022 recently, hoping that the Clang compiler might be a quick win.
Although Colossus compiled first time the Clang executable was over 20% slower than the MSVC one
YMMV!
Mike Sherwin wrote: ↑Tue Dec 07, 2021 4:52 am
Today I downloaded MSVC 2022 and enabled the clang option. I wrote a little first program just to see if it will work for me. It ran just fine despite the compiler giving 3 diagnostic errors. I really don't want my code littered with false errors. I'm wondering just how many of these type idiosyncrasies there would be in a fully developed chess engine? However, from what I've seen it appears that clang produces faster executables. And that would be compelling if it were not for non chess engine examples running just slightly slower than standard MSVC in many cases. But, also Mar (and I think Gerd) said that clang understands my SISSY bitboard code much better than other top compilers which can make a sizeable difference in n/s. When Bricabrac was compiled with clang there were 1193 actual errors and it would not compile. So where does this leave me? idk, please help!
Side note: In MSVC 2019 I had to turn off Whole Program Optimization because every so many games it would flake out and become buggy. In MSVC 2022 Whole Program Optimization works just fine.
I also tried VS2022 recently, hoping that the Clang compiler might be a quick win.
Although Colossus compiled first time the Clang executable was over 20% slower than the MSVC one
YMMV!
????? How did you get bit scan forward working in C#, or, were you using C++? I too am disappointed in VS2022, Perhaps we should all tell Microsoft what we need and ask them to revise immediately, if not sooner.
Mike Sherwin wrote: ↑Tue Dec 07, 2021 4:52 am
Today I downloaded MSVC 2022 and enabled the clang option. I wrote a little first program just to see if it will work for me. It ran just fine despite the compiler giving 3 diagnostic errors. I really don't want my code littered with false errors. I'm wondering just how many of these type idiosyncrasies there would be in a fully developed chess engine? However, from what I've seen it appears that clang produces faster executables. And that would be compelling if it were not for non chess engine examples running just slightly slower than standard MSVC in many cases. But, also Mar (and I think Gerd) said that clang understands my SISSY bitboard code much better than other top compilers which can make a sizeable difference in n/s. When Bricabrac was compiled with clang there were 1193 actual errors and it would not compile. So where does this leave me? idk, please help!
Side note: In MSVC 2019 I had to turn off Whole Program Optimization because every so many games it would flake out and become buggy. In MSVC 2022 Whole Program Optimization works just fine.
I also tried VS2022 recently, hoping that the Clang compiler might be a quick win.
Although Colossus compiled first time the Clang executable was over 20% slower than the MSVC one
YMMV!
????? How did you get bit scan forward working in C#, or, were you using C++? I too am disappointed in VS2022, Perhaps we should all tell Microsoft what we need and ask them to revise immediately, if not sooner.
Thanks guys! I have gotten it down to only two errors. Those should go away when the bit scans are replaced by __builtin_clzll(bb). But I suspect the compiler took an early out. There are probably many more errors to find. As far as Whole Program Optimization it works now under 2022 and produces a slightly faster executable. Microsoft fixed my bug, lol. Really sorry to see 20% slower performance for Colossus.
