4 ms·

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, jus

by xvilka 4y ago

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_Abstraction.pdf https://llvm.org/devmtg/2020-09/slides/CIL_Common_MLIR_Abstr...

frutiger 4y ago
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 https://en.cppreference.com/w/cpp/compiler_support#cpp20
- xvilka 4y ago
  It absolutely worse in pure C standards and library support though.
  - hvs 4y ago
    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-support?view=msvc-170 https://learn.microsoft.com/en-us/cpp/overview/install-c17-s...
- jcelerier 4y ago
  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.
  - swatcoder 4y ago
    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.
    - jcelerier 4y ago
      No, those were actual language issues, not missing headers or things like that. For instance: https://developercommunity.visualstudio.com/t/if-constexprrequires----in-a-lamb/10293106 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-constexprrequires----broken-in/10162506 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.
- Kranar 4y ago
  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.
- simplotek 4y ago
  > 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.
cma 4y ago
Would they have to write off MSVC as a capital loss?
cmovq 4y ago
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.
- xvilka 4y ago
  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.
  - FrostKiwi 4y ago
    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%.
  - ynik 4y ago
    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.
  - TinkersW 4y ago
    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.
riskneutral 4y ago
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++.
pjmlp 4y ago
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.
- maxloh 4y ago
  Which is the first/second one?
  - pjmlp 4y ago
    VC++, and GCC. Then there are plenty of other ones following up clang. https://en.cppreference.com/w/cpp/compiler_support/20 https://en.cppreference.com/w/cpp/compiler_support/20 The list still misses a few proprietary ones on the embedded space.
- xvilka 4y ago
  > 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.
  - pjmlp 4y ago
    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.
    - gpderetta 4y ago
      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 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.

by xvilka 4y ago

frutiger 4y ago

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 https://en.cppreference.com/w/cpp/compiler_support#cpp20

xvilka 4y ago
It absolutely worse in pure C standards and library support though.
- hvs 4y ago
  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-support?view=msvc-170 https://learn.microsoft.com/en-us/cpp/overview/install-c17-s...
jcelerier 4y ago
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.
- swatcoder 4y ago
  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.
  - jcelerier 4y ago
    No, those were actual language issues, not missing headers or things like that. For instance: https://developercommunity.visualstudio.com/t/if-constexprrequires----in-a-lamb/10293106 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-constexprrequires----broken-in/10162506 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.
Kranar 4y ago
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.
simplotek 4y ago
> 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.

cma 4y ago

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

cmovq 4y ago

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.

xvilka 4y ago
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.
- FrostKiwi 4y ago
  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%.
- ynik 4y ago
  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.
- TinkersW 4y ago
  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.

riskneutral 4y ago

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

pjmlp 4y ago

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.

maxloh 4y ago
Which is the first/second one?
- pjmlp 4y ago
  VC++, and GCC. Then there are plenty of other ones following up clang. https://en.cppreference.com/w/cpp/compiler_support/20 https://en.cppreference.com/w/cpp/compiler_support/20 The list still misses a few proprietary ones on the embedded space.
xvilka 4y ago
> 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.
- pjmlp 4y ago
  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.
  - gpderetta 4y ago
    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 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.