my rant against MS-Windows

[abulmo2]

Following a recent discussion viewtopic.php?t=85879 I decided to see if I can improved a little my program MPerft that was favourably quoted here. After some changes I made under Linux with success, getting a 10% speed increase, it was time to compile my single file under windows. Here come a few deceptions:

1. I decided to use the C23 standard of the language. Indeed, C23 brought several standardized functions to manipulate bits with the header stdbit.h. Similar function were available for years on major compilers, but with undecipherable names like __lzcnt64 for counting leading zeros, but _tzcnt_u64 for counting trailing zeros, or __builtin_clzll, etc. As Visual Studio 2026 had been freshly released, I was full of hope that a three years old standard would have been included. But no stdbit.h although its implementation is trivial. Neither cl nor clang nor gcc (mingw) came with stdbit.h as all three are based on the libraries provided by Microsoft. I found the Pelles C compiler with support for C23 & stdbit.h, but this compiler was behind the other ones in term of performance. So, finally I had to reimplement the C23 functions I used in my program
2. Then, in order to get the fastest binary as possible, I decided to compile with a lot of optimisations, including LTO (link time optimization) & PGO (profile-guided optimization). Strangely, the latter did not worked. For PGO you compiled your program once. Then ran your program so that some statistics about the program were accumulated into a file. Then you recompile the program a second time, using the gathered information to better optimize the final executable. Unfortunately, according to the compiler version used, either no file were produced or an empty & unusable one. PGO used to work but not anymore. As I have no idea of what happened, I abdicate on this one.
3. Finally, I did some test to discover a very poor performance when using the hashtable, about 9 time slower compared to the Linux version. I finally found that the result was the bitfields I used to compact the hash entry to 16 bits was the culprit. Replacing the bitfields with mask & shift resolved this issue.

I know that the C language is poorly considered by Microsoft. Too bad.

[mar]

your rant has exactly nothing to do with windows and everything to do with microsoft C compiler and lack of proper support for modern C,
mainly library-wise.
you can try clang-cl as frontend (you have to install support first via vs installer)

you can still use clang/mingw on windows, especially if you want maximum performance (I compile the release builds of my engine with clang, because it produces the fastest binaries primarily thanks to llvm autovec)

[Joost Buijs]

You can also use the Intel C/C++ compiler which is based on clang, it produces faster executables than clang (even on AMD systems), and PGO works out of the box. It integrates with Visual Studio as well. The current version is (I believe) 2025.3.

https://www.intel.com/content/www/us/en ... nload.html

[Bo Persson]

It is well known that the layout of bitfields is not specified by the C standard, so historically they have been different on Windows and Linux. So totally non-portable.

"Manual" shift and mask has been the way around this.