4 ms·
This might be a stupid question. But is there performance degradation between versions of c++? I saw a couple of stack overflow questions last week of people c
by philliphaydon 4y ago
This might be a stupid question. But is there performance degradation between versions of c++?
I saw a couple of stack overflow questions last week of people complaining about c++ 17 being slower 14, and 14 being slower than 11.
But I find it hard to believe. I just started learning c++ recently and can’t find a conclusive answer.
- d110af5ccf 4y agoThose are just versions of the standard. What people would be comparing is the performance of particular implementations. It's entirely possible that a less mature implementation would have problems.
- philliphaydon 4y agoYeah that makes sense, thanks.
- kadoban 4y agoIf you're writing the same code, almost certainly not. The only way there would be would be if the compiler either can't optimize something as well because the lang changes requirements (this seems unlikely), or if they have bugs or inefficiencies because they haven't spent much time on the new standard. If you're using new stuff from the new standard, they could be slower or faster or undecidable, really depends.
- jcelerier 4y agoThere is at least one language-enforced performance improvement: C++17 enforces some amount of RVO. Thus some stuff that would have been copied in previous standard is now not anymore. More standard types supporting move semantics & such also mean that generic code which correctly calls std::move / std::forward may do fewer copies the more recent standard you use.
- pclmulqdq 4y agoThe "idiomatic" version is slowly getting slower because the idioms are getting higher-level and more expressive. If you don't use the idioms, you can have the same speed. Smart pointers (including unique_ptr<Foo>) have non-zero overhead compared to Foo*. The object oriented parts can introduce significant slowdowns. Template code can have huge code footprints if you are not careful, which slows things down. If you are looking for cycle-level performance, you likely need to use a more C-like subset of the language, but you can still use many conveniences like RAII and the smart pointers with 0 overhead (when construct/destruct are not in the critical path).
- ncmncm 4y agoThe above is commonly encountered, but not good advice. Most important, defend your hot path against incursions. E.g., don't pass smart pointer arguments around on hot paths. That is what matters. New language features are not slower than old features. But there are slow constructs to use carefully. Which they are will always surprise you, usually pleasantly. For example, almost everything around lambdas is fast, fast, fast, except =capture. Measure often. Look for surprises.
- jcelerier 4y ago> Don't pass smart pointer arguments around on hot paths. oh this so much.. I remember optimizing a particle system which would copy a shared_ptr for each particle on every update operation... IIRC just switching to references ended up being 10+ times faster
- latency-guy2 4y agoIf you can design your system so you rarely if ever use pointers, that would be the single best thing you can do for your C++ codebase I like to enlighten my interns every summer about the reality of pointers, and how much of a noob trap they are, and that yes, their professor lied to them in some ways
- pclmulqdq 4y agoI literally said not to construct or destruct smart pointers on the hot path. Also, my experience with lambdas has been otherwise. There are a lot of cases where lambdas need a heap allocation when you otherwise wouldn't. However, being able to use FP ideas can make up for that.