Comment by pkolaczk | Hacker News Reader

Comment by pkolaczk | Hacker News Reader

Parent Full thread

Except many provided abstractions are not really zero-overhead and it is even debatable if they are lower-overhead than abstractions found in the higher level languages (like mentioned here Java or C#).

Use std::string everywhere and the (re)allocation rate / fragmentation will make your allocator very sad. C-style strings are not "fast" per-se, but at least they make all the overhead explicit.

Use std::shared_ptr for everything and you'll end up with a higher overhead than any proper GC, particularly on a multicore system.

Use templates too much and your code size will blow away any L1 cache very soon.

Use std::mutex/std::lock to protect shared state and it is going to cost you much more than synchronized in Java, which Java often turns into a noop, but C++ compiler can't.

Use virtual functions and (in all except very trivial cases) they will prevent strong opimizations like inlining in many cases where C# or Java would have no problem.

Want to have safe array access? Sure, still possible to add range checks (e.g. use at instead of []), but are you really sure C++ compilers are as strong in eliding these checks as compilers for the languages with mandatory array bound checking?

Oh, you can even go the Java/C# style very heavily and use Boehm GC. Because you can. Who said C++ is lower-level? Except it is nowhere near the performance levels achieved by proper modern GCs.

The point isn't necessarily about whether C++'s abstractions are faster than Java's, the point is more that you aren't always forced to use them. If you are willing to commit to the size of your string at compile time, you have the option to use char[N] instead, avoiding heap allocations. Or you can use a stack-based allocator for std::string.

The thing about templates is misleading. Sure, if misused they can hurt your cache. But they also move branching from run time to compile time, which is a very good thing. Google some benchmarks of C++ sort vs C qsort; the former is much faster because the comparator can easily be inlined.

The templates used in my post, for example, either bloat the code not at all, or very little. They are either generating tiny functions that get inlined anyway (like ArrayView; once a function is inlined its irrelevant whether it came from a template or not for code bloat purposes) or they are generating code that would just need to be written by hand (like make_contiguous).

I've actually personally witnessed two fairly detailed accounts of people that actually got themselves into situations where template or template-like bloat became a performance negative, relative to the benefits they provided. They didn't cite a cliche about code bloat, they actually benchmarked and found the cost. What both of them were doing was very extreme; nobody who's not using very extreme template techniques (and therefore is sold on it) is hitting that point.

Sure thing, C++ is now very slow. That's why big projects like LLVM/Clang, WebKit, Gecko, Internet Explorer, AutoCAD, all Adobe products, all AAA 3D games and most indie ones use C++ instead of Java. If they knew back then when they started that Java and C# have lower overhead than C++!

Funny you listed mostly desktop Windows applications, where C / C++ API were just the only choice in the times when these applications were born. All of the three (Java, C# and C++) are used in performance-critical applications these days, but you just need look at computing as a whole, and not just at a tiny part of the market (desktop).

Also, not sure why if someone points to the obvious places where C++ could be slow, people treat it personally as an attack on "their" language. The fact that many high-level abstractions are not-free in C++, doesn't preclude it from being still highly performing, particularly if you know the cost of these abstractions and you know when to avoid them.

Reply on news.ycombinator.com