Hacker News Reader

Comment by Const-me | Hacker News Reader

Visual studio C++ compiler is very comparable to the rest of them. I think the OP got screwed by cmake. While it technically supports Windows, the level of support is not great.

To make fast binaries with Visual C++, use Visual Studio to create and configure the project. The most important settings are following:

• C/C++ / Code Generation / Enable Enhanced Instruction Set

• C/C++ / Optimization / Whole Program Optimization

• Linker / Optimization / Link Time Code Generation

While it’s technically possible to set up the correct VC++ options with CMakeLists.txt, it’s relatively hard: need to detect VC++ compiler, and pass these weird command-line switches. Most cross-platform C++ libraries aren’t doing that.

View on HN

The latter two flags are roughly equivalent to `-flto` on gcc/clang, and it's not a fair comparison to enable it for VC++ but not gcc/clang. (It seems that you can set(CMAKE_INTERPROCEDURAL_OPTIMIZATION ON) to make cmake enable lto).

  I told it to generate a VS solution to see what build settings it had applied.. and it is set up very poorly, not surprising performance is ass.

This is release settings:

intrinsics = off

SIMD = off

whole program optimizations = off

link time code gen = off

Comparing lto vs not does make sense.

You'd want to compare lto vs lto and not vs not.

This is not vs not. It is a fair comparison in that sense

AFAIK the fastfloat benchmark is a single translation unit anyway. Whole program optimization and LTO buys you nothing there.

GCC and clang are both conservative with instruction set withou march option.

I'm often disappointed by MSVC codegen when examining it in godbolt, I'm not surprised by the results here.

interesting! the builder is making the program slow?

would be interesting to see the benchmark result using cl commands directly.

Microsoft got where they did by prioritising extreme backward compatibility, hence the SimCity on Windows 95 story - SimCity has a bug, Windows 95 specifically works around the bug so now SimCity works on Windows 95. For ordinary end user software this is unabiguously good news, for a compiler it's more of a mixed bag.

The ADK used a lookup db to apply those fixes though; it wasn't a global fudge. Windows compatibility has probably been the main differentiator over the decades and every break (vista driver signing, dropping support for a bunch of scanners/printers, os quality issues) then 10 and even more so 11 making upgrading a mess of seemingly huge hardware replacement costs for next to no user/use gains, has caused uproar. Hell even xp was a mess; windows compatibility mode barely did what it suggested; but the intention was there.

Reply on news.ycombinator.com