4

I work in trading firm and here latency matters a lot. The project assigns to me is developed using a mix of c and c++98 parts, But I believe we can make same project using C++11 without losing efficiency. As discussed with my seniors, they say you should stick with C and c++03 as they are efficient compare to C++11 at micro level. Can anyone highlight me If I go with C++11, will I get better results?

arun pal
  • 539
  • 4
  • 18
  • Depends what you're doing. For *really* performance critical stuff I use C, but I'm sure that's because I'm an old fuddy-duddy. – Bathsheba Nov 16 '17 at 08:21
  • 3
    C++98/03/11 are language standards - efficiency is (mostly) dependent on the actual code you write (and maybe how good the compiler you use is at optimizing). Saying C++03 is more efficient than C++11 doesn't make any sense – UnholySheep Nov 16 '17 at 08:23
  • 4
    Any C++03 is still valid C++11. The committee went to great lengths in order to ensure "old" code is still as good as it was if upgrading. Having said that, unless you *use C++11 effectively*, your results won't be stellar. – StoryTeller - Unslander Monica Nov 16 '17 at 08:23
  • Doesn't depend. C+ 11 is C++. In fact, you are probably using a C++ 17 compiler nowadays. Should you use C++ 17 and later constructs instead of the older ones? *DEFINITELY. Why manage types pointers manually when you have auto and `unique_ptr`? In fact, back in C++ 98, the non-standard `auto_ptr` was all the rage. Now even that is deprecated, replaced by better constructs – Panagiotis Kanavos Nov 16 '17 at 08:24
  • As for the seniors, yes, it's nonsense. There's no reason to write *non-standard* code. Or assume that you can implement a container or algorithm, or (shudder) tasks and futures better than the library writers? I bet they use pointer arithmetic instead of iterators and algorithms? And avoid references? How are you going to program against *multiple core machines*? Restrict yourself to only a single core? – Panagiotis Kanavos Nov 16 '17 at 08:25
  • 1
    Measure the program. Inspect the assembly listing. Show them the evidence. –  Nov 16 '17 at 08:26
  • And don't forget. There were a LOT of improvements in STL, streams, Boost in the last **14 years**. C++ addedd real Unicode support in C++ 11/14 with char16_t, char32_t, std::u16string, std::u32string. – Panagiotis Kanavos Nov 16 '17 at 08:29
  • 3
    Possible duplicate of [Can modern C++ get you performance for free?](https://stackoverflow.com/questions/27595429/can-modern-c-get-you-performance-for-free) – Klaus Nov 16 '17 at 08:29
  • @Klaus the new copy semantics! That's enough to give a huge boost! – Panagiotis Kanavos Nov 16 '17 at 08:30

4 Answers4

8

C++11 is faster, because moving of objects was introduced. Mainly the usage of this feature in the STL speeds up some applications a lot without any code change in user code. Applications can be programmed much more efficient then before. Also constexpr construction can result in much faster application startup, because objects can reside in flash space on small controllers instead copy them into ram. There are a lot more features which help to get the code more efficient. For example emplace_back for conatainers help to generate objects in place instead of creating & copy them.

C++17 introduces guaranteed copy elision, which speeds up also in a lot of use cases.

Klaus
  • 20,019
  • 4
  • 46
  • 90
3

This is mostly wrong.

Firstly, if you give C++03 compliant source to a compiler like GCC, it is very unlikely that the generated machine code will be any different if you specify --std=c++03 compared to --std=c++11.

Secondly, using features like auto and "range based for" will be neutral for efficiency. (There may be a few cases where Range-based-for will allow the compiler to optimize the evaluation of the termination condition more efficiently than a naive loop, but these will be rare.)

Thirdly, there are some features (like move semantics) which are actively beneficial for efficiency.

Finally, there are a few cases where naively written C++11 will be less efficient than the equivalent C++03 code. For example:

std::vector<std::vector<big_struct>> big_2d_array;
for (auto v : big_2d_array)
    do_stuff(v);

This will copy v and will be expensive. It needs to be:

for (auto &v : big_2d_array)
    do_stuff(v);

Note the reference. (I would also recommend const, but that's a separate issue).

  • ya, move semantics is one feature that is really beneficial for high performance code. we used it heavily in a image processing backend and it helped. – basav Nov 16 '17 at 09:09
  • `auto` **might** be helpful when the type of an expression isn't what the programmer thought it was, and the conversion has some cost – Caleth Nov 16 '17 at 09:35
  • @Caleth: Alternatively it might be harmful. If a function returns a `FooBuilder` which has an automatic convertion to a `Foo`, then capturing the result of the function as `auto` rather than `Foo` means the conversion will happen multiple times. – Martin Bonner supports Monica Nov 16 '17 at 10:05
  • But probably FooBuilder was just there to provide move semantics in some horrid hacky way? :-) – Gem Taylor Nov 16 '17 at 10:48
  • @GemTaylor Usually FooBuilder is there to provide a fluent interface to provide some, but not all, the 57 arguments to a constructor. All the heavy lifting is done in the "convert to Foo" function. – Martin Bonner supports Monica Nov 16 '17 at 11:14
  • Would the down-voter care to explain what I got wrong here so I can correct it please? – Martin Bonner supports Monica Jun 25 '19 at 13:26
0

C++ - the language - doesn't make any performance guarantees beyond complexity limit O(*) for various operations - mostly containers, and general concept of "you don't pay for what you don't use".

There are no significant changes to this (except maybe the new container types that might be a better fit in a few places).

[edit] I forgot: move semantics can significantly speed up an existing code base without any changes. (However, if you've been squeezing cycles, you probably won't benefit.)

However (there's always one in C++) compilers usually have improved. Notable sources of significant performnance gains are new technologies like link-time code generation and automatic vectorization that have become much more widespead and refined, and better support for contemporary CPU architectures.

Against a compiler upgrade speaks only the risk and cost of research and testing.

Gut feel: Your seniors shy away from the risk and the change.

"C and c++03 [...] are [more] efficient compared to C++11 at micro level" is bull. Unless your seniors didn't bother to learn the newfangled stuff introduced 20 years ago.

peterchen
  • 38,919
  • 19
  • 95
  • 176
  • And in fact the C++11 makes some stronger O(*) guarantees than its predecessors: std::list::size() for instance is now immediate rather than linear. – Gem Taylor Nov 16 '17 at 10:51
  • @GemTaylor: ...which is actually a tradeoff, because that makes splitting a list into two O(N) rather than O(1) - which is the original reason why this was left to the implementaiton. However, yes, since this can affect algorithm choice, "implementaiton defined" is a bad choice here, andsince split isn't an explicit list operation, this seems to be the right choice. – peterchen Nov 16 '17 at 11:02
  • Although the new splice is effectively what you are looking for from split. – Gem Taylor Nov 16 '17 at 16:49
-1

Honestly, this is highly dependent on the specific code snippet. C++11 is only a newer revision of the C++ language standard (ISO/IEC 14882:2011).

A newer revision only changes the grammar of certain expressions and statements, and usage of certain keywords, as well as introducing new (and useful) stuffs, like rvalue reference (T&&), auto type deduction (auto and decltype), variadic template parameters (template <typename... Args>) and so on. In spite of the fact that some introductions may help you write more efficient codes (e.g. move semantics), it essentially does not change the way compilers are required to generate CPU instructions from C++ source codes.

So in micro-instruction level, the compiled instructions from the same source would mostly remain the same under C++98/0x/11, so there should not be any observable difference in performance.

What in fact matters the more is the algorithm you choose and the specific implementation you write, as well as compiler optimization (usually -O# command line argument). With new standards, you are allowed to write faster codes with move semantics, range-based for loop, decltype(auto) (this one is C++14, though)


In fact, this code generates exactly the same assembly code, when language standards is the only different option supplied to the compiler:

#include <iostream>
using std::cout;
using std::endl;

int main() {
    cout << "Hello world" << endl;
    return 0;
}

But when you start working with STL, which always use the latest features whenever possible, then it starts to make a difference:

#include <iostream>
#include <string>
using std::string;

string getString(void) {
    string str("");
    for (int i = 0; i < 100000; i ++)
        str.append("A");
    return str;
}

int main() {
    std::cout << getString() << std::endl;
    return 0;
}
iBug
  • 30,581
  • 7
  • 64
  • 105
  • When people talk about staying in C++ 03, the usually mean keep using that old compiler. The one that can't auto-parallelize or emit SIMD commands by inspecting the loops themselves. In that sense C++14/17 are faster. And don't forget STL, Boost et al. There's a LOT of improvement in the last 14 years – Panagiotis Kanavos Nov 16 '17 at 08:27
  • Furthermore, the new copy semantics mean a *huge* performance boost for the same code. – Panagiotis Kanavos Nov 16 '17 at 08:31
  • Why the downvotes? Or do we have a serial downvoter? Good thing there's a downvote bot that deletes serial downvotes. Don't know if it flags the downvoter too. – Panagiotis Kanavos Nov 16 '17 at 08:33
  • @PanagiotisKanavos : I hope the bot won't object to someone who downvotes all the answers to a single question. It is quite often the case that all the answers to a question are broadly similar (as here); they could all be wrong. – Martin Bonner supports Monica Nov 16 '17 at 08:36
  • @PanagiotisKanavos Serial downvoting targets **users**, not **questions**. We do have a serial downvoting detection bot and it does flag the voter in fact. – iBug Nov 16 '17 at 08:39
  • 1
    The c++11 generates faster code, especially because STL uses a lot of optimized c++ features. Simply compile a application and check it out. Apps using a huge amount of stl containers speed up a lot. So it is wrong to say "nonsens"! – Klaus Nov 16 '17 at 08:41
  • @Klaus I'm sure `nonsense` refers to the devs that say there's no difference and one should stick with the 14-year old standard, if not the 19 year-old one. – Panagiotis Kanavos Nov 16 '17 at 08:42
  • 1
    @PanagiotisKanavos: In context with `C++11 is as simple as a newer ...` it sounds simply wrong to me. There are so much new features in c++11 which results in more efficiency, that this answer points to the wrong direction. – Klaus Nov 16 '17 at 08:46
  • @Klaus Thanks for pointing out. I've changed the expressions. – iBug Nov 16 '17 at 08:47
  • @iBug: Your answer still is not better. `Is only...` no! It improves a lot, especially for efficiency. So it generates faster code as mentioned in my answer and other comments. So your answer is wrong for me! – Klaus Nov 16 '17 at 08:49
  • Adding move semantics is a big boost. The compiler won't generate the same assembly for a move as it would have done for a copy... – M.M Nov 16 '17 at 09:03