Re: [boost] BOOST_NO_CXX11_CONSTEXPR and msvc-14.0

Subject: Re: [boost] BOOST_NO_CXX11_CONSTEXPR and msvc-14.0
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-07-25 08:42:41

On 24 Jul 2015 at 21:46, Andrey Semashev wrote:

> Competition is good, on that I agree with you. But I don't think MSVC is 
> the compiler that drives the competition currently.

I personally think you're very wrong on this.

I think there is a "two speed" C++ ecosystem. The largest which is 
the "slow ring" is paced by the lowest common denominator, and that 
is MSVC.

Therefore VS2015 is the most important release of Visual Studio for 
all C++ users since VS2003 (which was the first to implement most of 
C++ 98). VS2015 is the release which fires the gun on no C++ 
programmer writing C++ 03 code any more.

If you even look at the Boost usership, there is a ton of people 
still on VS2005. That's because later VS's didn't offer anything new 
which was compelling for a C++ user. A quick informal straw poll at 
C++ Now found almost all of these had been experimenting with VS2015 
CTP and were expecting to jump straight to VS2015.

So how does this drive the competition? Because clang can't push too 
far ahead of the majority. And MSVC sets what the majority is.

> If anything, this 
> compiler, being the main compiler on Windows, has been an absolute 
> embarrassment in terms of language support for many years. It still is 
> in several areas, even though it's catching up and VS2015 claims to 
> support C++11 and C++14 more fully.

VS2015 has about clang 3.3 levels of C++ 11 and 14.

> As for clang, I've surely been 
> hearing that it is about to conquer the world for the last several years 
> but I don't see that happening. I don't think it would even in the 
> absence of MSVC.

clang's development has slowed recently because of Modules and MSVC 
compatibility. Once those two have cleared (they are both enormously 
hard), pace will pick up again.

> All that does not diminish the efforts of each dev team. I'm pleased to 
> see that MS is trying to improve their compiler at a faster pace and 
> with more frequent releases.

They delivered a new C++ spec in four years as compared to five years 
with the C++ 98 standard. That's 20% faster!

> >>> It's vastly faster to compile, like 5x-10x faster as it's not an AST based
> >>> compiler like clang and GCC.
> >>
> >> This is interesting. Which (preferably public-available open source)
> >> project(s) have you compiled with all three, and what were the build times?
> >
> > It depends on if you use precompiled headers or not. I would assume
> > anyone sane in Boost-land does.
> 
> I didn't research this but my impression has always been that 
> precompiled headers mostly hide the slowness of the Windows filesystem. 

That doesn't explain the benchmarks I posted though where I was 
comparing MSVC on Windows to clang and GCC on Linux.

> When I was building natively on Windows, I noticed that the same code 
> compiled with MinGW on Windows much more slowly than with gcc on Linux, 
> on the same machine.

Correct. This is because GCC uses the stat() call to search header 
path locations for the existence of a file. The stat() call requires 
seven syscalls on Windows to synthesise the information, none of 
which is actually used by GCC. If you manually pare down the 
locations it searches you'll see a corresponding improvement in 
speed.

I patched clang for the BB10/QNX dev stack to use PathFileExists() on 
Windows and saw a 40% performance improvement :)

> > https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a16.BUILD:C
> > onsiderdefaultingtoheaderonlybutactivelymanagefacilitiesforreducingbui
> > ldtimes for some empirical numbers. tl;dr about 2x faster in debug
> > than clang, about 3x faster in release than clang. clang itself is 2x
> > faster than GCC in debug.
> >
> > AFIO is very easy on the compiler as it's a tiny simple library. The
> > more templates you feed it, the relatively faster MSVC becomes
> > because it doesn't do two phase lookup i.e. it completely ignores
> > template code until instantiation and neither clang nor GCC do that.
> 
> I can't see how a non-conforming behavior is an advantage.

I know what you mean. Still, in practical terms I don't much like 
waiting around to see if my new code works, and MSVC delivers that 
for me.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/