I also tested MSVC vs ClangCL recently, because someone requested MSVC support, and I have no Windows machine. mingw cross worked fine for several years. on apple and linux. So I installed clangcl and cross-compiled the project on linux to windows via clangcl, fixed all missing compat pieces (not much, because MS got much better recently, mostly adding some _ prefixes to std functions), and then tried a native MSVC CI (Github Actions and appveyor).
clangcl indeed caught a lot of problems, but not all. msvc still deviated more than with chrome. The clangcl/msvc wrong size reports were very good!
Here are the additional MSVC fixes I had to add, over clangcl:
VS2019 specific fixes, __VA_ARGS__, __attribute__, suppress warnings
* __VA_ARGS__ macro support (illegal ...)
* __attribute__ only with __GCC__
* suppress C4101 uninitialized recount warnings, and strcpy
insecure warnings.
* no proper const var support
(with the even weirder error: cannot allocate an array of constant
size)
* much stricter typecasts (silly cl compiler)
* strict dllexport/dllimport decls: fix various omissions
clangcl is not error compatible to msvc, msvc errors much more.
While I was there: tcc was fine, for chibicc I had to file some PR's with large files, and pcc is currently broken, some tricky cpp regressions, which I couldn't fix.
An other option that is not mentioned is cross compiling with clang-cl on a Linux host to a Windows target. I believe this is much harder to set up, but it could have better compile performance than compiling on Windows. It would be pretty funny if compiling with clang-cl on WSL would be faster than compiling with clang-cl on Windows natively.
Did that. Fastest is msvc natively via cmake (3m). Slowest is mingw on windows via autotools (>30m).
clangcl vs msvc was not much difference (less than 30s diff).
linux builds are from 3m (cmake) to 8m (autotools).
clangcl on WSL it would be much faster, but msvc natively would beat it, esp. if you turn off the virus scanner and inherited filesystem permissions.
The sheer amount of additional msvc warnings (integer promotion should not really warn) would slow it down though.
So basically no reason to keep flogging this incompatible dead horse of MSVC. Microsoft should just join the project and help to improve the LLVM ecosystem, just like many other companies do. One thing they can help is the project of separating C and C++ compilation in multiple steps by creating something was referred as CIL[1] (C intermediate language for LLVM), like some other LLVM languages do - Rust, Swift, etc.
MSVC tends to like to tick off checkmarks that the other compilers would be hesitant to check off. So yes, MSVC can claim to implement modules and co-routines and pretty much all of the standard library, but in actuality it does so in a way that is unreliable and full of bugs.
GCC and clang have those same features, but they avoid including them in their main distribution and instead have experimental/development forks that people can use, opting to include them only when they meet a much higher standard than Microsoft.
in theory yes, in practice this morning again I tried the new version of VS and encountered dozens and dozens of compile errors in standards-confirming C++20 code (which works fine in gcc and clang), some for fairly basic C++20 stuff.
This might not be your issue, but if you haven’t tried that transition before, the first batch of errors is often because secondary header includes incidentally let your code work in those other toolchains despite you not including required headers yourself. It happens annoyingly often, but it’s not a flaw in the toolchain. The MS headers are just structured differently.
I try building my code every once in a while against MSVC because it has some useful warnings but am very burn out with code breaking on almost every minor version - I shifted all my serious work to clang+libc++ on windows a few years ago already. E.g. I've reported something like 50+ bugs, internal compiler errors, etc... to MS over the years and only a couple for clang even though I use it much much more.
> Except MSVC is far ahead of Clang[1] (and leagues ahead of Apple Clang) when it comes to C++ standards conformance.
I feel this is a red herring.
People use AppleClang because it ships with Xcode and is integrated with it. Those who are stuck with Xcode will not choose msvc's support for C++20 as a good enough reason to drop everything.
With Clang, the main differences with MSVC boil down to a couple of minor features that are hardly showstoppers, such as simplifying implicit lambda captures.
Between being able to use clang and all it's tooling and being stuck with msvc, using clang is far above in importance.
There are a lot of great things about both the MSVC and LLVM C++ compilers and the world is a better place because there are multiple, actively maintained and highly capable compilers for C++.
Not for a release builds though. Moreover, in general Windows compilation is always slower than on Linux, they should improve their OS FS IO performance.
This is in part because of how Windows Defender works. It scans created binaries, blocking them whilst doing so and interferes with compilation. This is the reason there often exists a hidden Windows Defender exception folder for developers. I have seen IT of 2 different companies setting this up now and there really is a time difference.
Whilst not quite on topic, this is especially catastrophic for anything that uses fork() and friends via Cygwin. (i.e. the MSYS2 ecosystem and the MinGW64 compiler suite). MSYS2 native `git add -> [tab]` halts the freezes command line for a second and turning off Windows Defender or using folder exceptions easily cuts compilation time by for Makefiles with multiple small files 30%.
Note that while Windows small file IO is slow; it's extra-slow on C:.
I have two partitions (C: and D:) on the same SSD, and creating a whole bunch of empty files (1.txt to 10000.txt) runs 2x faster on D: than it does on C:.
I believe there's two reasons for this:
* C: has extra IO filter drivers for system integrity that eat up CPU
* C:, by default, enables 8dot3names for compatibility (e.g. with software that expects C:\Progra~1\ to work as an alias to C:\Program Files\). On other partitions, 8dot3names are disabled by default.
So I recommend putting the OS on a separate partition from all development activities. Also, don't forget to exclude D: from Windows Defender.
This was measuring a full build, but in the real world what matters most is incremental builds.. where MSVC performs very well since it has incremental linking & compiling.
Also who even knows what this build was doing as it used CMake(garbage). It isn't clear what compiler settings were enabled either since again CMake.
That's surprising. I haven't used MSVC in almost a decade, but I remember being significantly slower to compile than both GCC and clang. Did it improve since?
That's surprising. I haven't used MSVC 6 in over two decades, but I remember gcc2.95 (redhat patch was 2.96) being significantly slower and clang didn't even exist. But we had pretty cool trance music at the time.
> Did you read the article? MSVC compiles twice as fast as clang and has double the perf in debug builds.
To me that means absolutely nothing, as visual studio and msbuild fails to support basic features like compiler launchers, which enable using compiler cache tools like ccache or sscache.
While you're benchmarking compilers, I plug ccache and build projects with dozen of subpackages in under a minute with build servers maxing out on IO.
clang doesn't come with a state of the art IDE, GUI frameworks, hot code reloading, among lots of other goodies.
Then again, maybe Microsoft should join the other C and C++ vendors that have forked clang and hardly contribute anything to upstream other than LLVM stuff, which is why clang is now enjoying a comfty third place in ISO conformance, after Apple and Google decided to re-focus on their own languages.
No they cannot, clangd isn't compiler agnostic, and Clion's dependency on it is now being hindered by clang's slow pace, even if the goal is to target another compiler.
To be fair, from a language point of view, clang is not actually lagging that badly. I don't know how reliable is this: https://en.cppreference.com/w/cpp/compiler_support, but language-wise clang is sort of keeping up.
libc++ is indeed in a sorry state, but at least on linux clang is usually used against libstdc++ so it is not a huge deal. Personally I'm worried about clangd falling behind, but so far I see very very little that it doesn't understand.
Calculate the build time of the same source code on Windows and Mac or Linux and take your own conclusions.
The game industry is attached to Windows, not because it's better for programming. It's because of the drivers and the available tools.
clangcl indeed caught a lot of problems, but not all. msvc still deviated more than with chrome. The clangcl/msvc wrong size reports were very good! Here are the additional MSVC fixes I had to add, over clangcl:
clangcl is not error compatible to msvc, msvc errors much more.While I was there: tcc was fine, for chibicc I had to file some PR's with large files, and pcc is currently broken, some tricky cpp regressions, which I couldn't fix.