6

I know you can get a performance boost when compiling with a C++11 compiler instead of a C++03 compiler (see this question).

But can I expect a performance boost when going from a C++11 compiler to a C++14 compiler?

If so, can you show me a code sample that will be faster when compiled with C++14 instead of C++11.

Community
  • 1
  • 1
Romain
  • 1,155
  • 1
  • 14
  • 28
  • 10
    That depends on your code. – Arun A S Apr 29 '15 at 16:24
  • 1
    I don't think this would depend on the language standard, but of better optimization capabilities of more modern compilers. – πάντα ῥεῖ Apr 29 '15 at 16:26
  • 3
    I've seen so many examples here of programs that spend all their time calling library functions or I/O, and people wonder if the compiler can make them faster. If .01% of time is spent in the code the compiler sees, that time could be shrunk to 0, and you would never notice. – Mike Dunlavey Apr 29 '15 at 16:27
  • @πάνταῥεῖ Well, sometimes the same syntax uses newer semantics and related mechanisms, which are (or can be) faster. I think this is the premise of the question. In this meaning, newer standard "could improve performance", although I say this with a bitter taste =). – luk32 Apr 29 '15 at 16:27
  • 1
    I can think of at least one post-C++11 [core language tweak](http://stackoverflow.com/questions/25875596/can-returning-a-local-variable-by-value-in-c11-14-result-in-the-return-value-b/25876175#25876175) that should result in improved performance on identical code, but that one was made via a DR. – T.C. Apr 29 '15 at 16:29
  • The `can you show me a code sample that will be faster when compiled with` part of the question make me lean towards thinking this is too broad. – Shafik Yaghmour Apr 29 '15 at 16:47

3 Answers3

11

There is a core language change in C++14 that allows the implementation to merge memory allocations, see N3664. If your compiler/optimizer takes advantage of this allowance, you may see a performance improvement.

T.C.
  • 123,516
  • 14
  • 264
  • 384
6

A fully compliant C++14 compiler with all defects solved has at least one bit of code it is mandated to make more efficient than the C++11 version.

struct one_byte { char x = 7; };
struct cheap_move {
  std::vector<one_byte> state{1000000}; // 1 mb of state, cheap to move
};
struct test_type {
  test_type(test_type const&)=default;
  test_type(test_type &&)=default;

  // can construct from a cheap_move via either copy or move:
  test_type(cheap_move const&y):x(y){}
  test_type(cheap_move &&y):x(std::move(y)){}

  cheap_move x;
};

test_type test_func() {
  cheap_move m;
  return m;
}

the return m; in a C++11 compliant compiler will copy 1 megabyte of memory. In a C++14 compiler with defect 1579 implemented, it will copy 3 pointers (well, move 1 vector).

This is because in C++11, the implicit convert-to-rvalue only occurs if the types match exactly. Under that above defect report (listed as C++14), it occurs if there is an rvalue-consuming constructor that matches. So C++14 moves into the return value, while C++11 copies into the return value.

(@T.C. tracked down the defect report above).

Note that not all C++14 compilers implement that fix to that defect. Both clang and gcc over at http://coliru.stacked-crooked.com/ at this point do not implement the fix to that defect in C++14 or C++1z mode.

A less contrived example is:

struct modulate {
  std::vector<double> state;
  double operator()(double x)const{
    double r = 0;
    for (double v:state) {
      r*=x;
      r+=v;
    }
    return r;
  }     
};
std::function< double(double) > f( std::vector<double> state ) {
  auto m = modulate{std::move(state)};
  return m;
}

The return implicitly moves in C++14, and copies in C++11.

Note that a simple std::move(m) would make C++11 do the same thing as C++14, but the rule that "you don't move returned local variables" leads people to avoid that (as it blocks elision): such an "error" would be common, given the general rule.

In C++11 this "error" leads to inefficiency above, but it is no longer an error in C++14.

T.C.
  • 123,516
  • 14
  • 264
  • 384
Yakk - Adam Nevraumont
  • 235,777
  • 25
  • 285
  • 465
5

Not inherently.

You can probably expect performance to generally increase as compilers get better at code generation over time, so newer compilers would generally be considered "better" and more likely to excel at optimisation than older compilers.

But will you automatically get a faster program just by switching between C++11 and C++14 mode? No.

Lightness Races in Orbit
  • 358,771
  • 68
  • 593
  • 989
  • So there were no changes similar to move semantics that would result in speedups at a language level? – Mark Ransom Apr 29 '15 at 16:32
  • Ummm... are there no new semantics and mechanisms that would make programs faster? I mean, going from 03 to 11, you can write a code that has same syntax and will use `move` semantics in c++11. It is fairly easy then to write a code that gets "boosted". The answer is a strong statement, that there were no such changes going from 11 to 14. – luk32 Apr 29 '15 at 16:33
  • 5
    I wonder, what has changed from C++11 to C++14 and why does that not improve performance? I remember reading something about that now compilers can move-rahter-than-copy in more places than in C++11, but forgot the details. Do compilers implement that behavior in their C++11 mode aswell? Are there more cases like that and how does it affect the answer? Is your answer core-language specific or does it also consider the library evolution? Thanks. – Johannes Schaub - litb Apr 29 '15 at 16:33