Regular Visual Studio versus ClangCL | Hacker News Reader

Regular Visual Studio versus ClangCL

lemire.me

53 pointszdw36 comments

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.

[1] https://llvm.org/devmtg/2020-09/slides/CIL_Common_MLIR_Abstr...

Except MSVC is far ahead of Clang[1] (and leagues ahead of Apple Clang) when it comes to C++ standards conformance.

1. https://en.cppreference.com/w/cpp/compiler_support#cpp20

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.

No, those were actual language issues, not missing headers or things like that. For instance: https://developercommunity.visualstudio.com/t/if-constexprre...

Which is extremely frustrating when i reported a very similar issue in 17.4 which was reported as fixed (https://developercommunity.visualstudio.com/t/if-constexprre...), etc.

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.

It absolutely worse in pure C standards and library support though.

Until recently Microsoft didn't even pretend to support C, they basically just built a C++ compiler. But they have really stepped up their support in the past couple years: https://learn.microsoft.com/en-us/cpp/overview/install-c17-s...

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++.

Did you read the article? MSVC compiles twice as fast as clang and has double the perf in debug builds.

LLVM has an amazing optimizer but the compiler is just so much slower even on unoptimized builds.

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.

MSVC was faster than Clang on Windows, but both were slower than Clang on Linux and Mac. And Clang was faster in release builds.

The debug build took 2 min with Visual Studio vs 2:51 for ClangCL. That's not twice as fast.

Not only VC++ is better in ISO C++ support.

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.

> state of the art IDE

Is that MSVS you are talking about? I don't think even Microsoft's own marketing team would've been so bold as to actually say something like that...

> hardly contribute anything to upstream other than LLVM stuff

Still better than contributing nothing.

> clang doesn't come with a state of the art IDE, GUI frameworks, hot code reloading, among lots of other goodies.

These features are compiler-agnostic and can be easily built on top of clangd, cling, etc.

Enjoy 3rd place then.

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.

> clang doesn't come with a state of the art IDE,

What are you talking about? I use Clion just fine regardless of compiler.

> GUI frameworks, hot code reloading, among lots of other goodies.

Do you understand that those features have absolutely zero to do with compilers?

Which is the first/second one?

VC++, and GCC.

Then there are plenty of other ones following up clang.

https://en.cppreference.com/w/cpp/compiler_support/20

The list still misses a few proprietary ones on the embedded space.

Would they have to write off MSVC as a capital loss?

Resume, avoid Windows to compile anything.

Like the gaming industry I gather.

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.

Indeed, they lack incremental linking and hot code reload like Visual Studio, unless one is willing to buy something like Live++.

Reply on news.ycombinator.com