3 ms·
> The real wins in performance for real world applications are in terms of algorithmic complexity. A poorly implemented solution in C++ will still be slow, the
by claudius 12y ago
> The real wins in performance for real world applications are in terms of algorithmic complexity. A poorly implemented solution in C++ will still be slow, the language does not make it fast.
Yet a well written implementation in C++ will still be faster than an equally well-written implementation in, say, Python or Haskell or whatever. Not in an asymptotic sense, but easily by a factor ranging between two and 200. For me, this can be the difference between waiting a couple of weeks or half a year for some computation to complete :)
> Just saying C++ is fast does not make programs written in C++ actually fast.
Of course not, but C++ makes it possible for programs written in C++ to be fast.
- pkolaczk 12y agoComparing to Python or Haskell, maybe you're right, but not to CLR-based or JVM-based statically typed languages. Very often the differences between Java/C# and C++ are the same order of magnitude as differences between various C++ compilers. The mythological C++ performance is often overstated (there are some performance advantages in C++ but they are rarely big enough to justify language choice).
- tfinniga 12y agoI think C++ is justified when you're constrained by CPU, RAM, or other resources. That is, if the limiting factor is development speed, or network traffic, or waiting for user input, then C++ probably isn't going to be worth it. But if in your problem area you can get a competitive advantage by being faster, using less memory, or tightly controlling other resources, then C++ is probably the right choice. If you really need it, you can use some inline assembly too. For example, look at a VM's JIT compiler: it needs to capture a profile from a running application, analyze hotspots in that profile, recompile those on the fly to native code, and coordinate with the VM to swap that out on the fly. The more time and memory that is used to do all this, the slower every application on the VM will run. Since there's a very constrained environment, C++ is a good choice for JIT compilers. And if you look at the CLR/VES or JVM, they are indeed written in C++.
- pkolaczk 12y agoFair enough. But the number of resource-constrained systems is pretty low these times. A phone, watch, dishwasher or xero machine are no longer resource-constrained. Also, C++ is not really shining IMHO in very-constrained environments - at least not "modern C++" dialect. Template-heavy libraries can blow up code-sizes pretty severely and dynamic memory allocation happening behind-the-scenes in the standard library is not free either. So for those very constrained systems, pure C or a very tiny subset of C++, i.e. C with classes, no exceptions, no templates, might be often a better choice.
- tfinniga 12y agoYeah, I realize my view on this is a bit skewed. A lot of the examples people give where C++ is still justified are things that I have done in my career - image processing, video editing, rendering software, CAD software, solving large sparse matrix systems, etc. On the other hand, there is a reason why native apps are popular on the iPhone. Likewise, some games are programmed in high-level languages, but the performance advantage of C++ keeps it dominant in games. Between games and mobile devices, I'd say C++ isn't going anywhere any time soon. C++ can indeed be very bloated, like you say. On the other hand templates do allow for code reuse without the function call overhead.. I believe std::sort is faster than qsort. For me, if there was another language that was as well supported as C++ but allowed higher-level structures and programming methods, I'd be very much in favor of it. For now it looks like new versions of C++ are the closest there is. Nobody really likes C++ for its elegance, it's just a very practical choice.
- deong 12y agoAn order of magnitude is a hell of a lot. I did some extensive comparisons of C++, Java, and C# back when I was working on my dissertation. Admittedly, this was about 10 years ago now, but at the time, the best I could get with Java was about a factor of 2.5 slower than C++. C# was similar, but I don't recall the specifics now. When you read a language shootout, a lot of times a factor of 2-2.5 times slower than C or C++ is considered to be "good enough". If you get your Clojure code that fast, everyone calls it a day. For me, a typical run of my experiments took about 3 weeks on (I think) a Core 2 Quad using all four cores. So in the best optimized Java I could find, that would have been about 5 extra weeks spent waiting around for results, and I had several cycles like that. All told, I imagine it would have added a year to my work. I'm not necessarily picking on you here. You did say "rarely", not "never". But I don't think a lot of people are aware of how common it is for a factor of two to be a complete deal-breaker.
- pkolaczk 12y agoA factor of two difference is something that can be a result of using different C++ compilers or even different versions of the same compiler. See this: http://lemire.me/blog/archives/2012/07/23/is-cc-worth-it/ http://lemire.me/blog/archives/2012/07/23/is-cc-worth-it/ Particularly the comments section contains various results obtained from different compilers / versions. Variablility is higher than 2x for GCC. Comparing with Clojure is not fair, because it is not really statically typed, and known to be much harder to optimize for speed than e.g. pure old Java.
- deong 12y agoI tossed out Clojure as a random language -- all my testing was done with the most efficient Java and C# I could write. The link is fine, but only shows micro-benchmarks. It's much easier to get a 3x difference in execution speed between compiler versions when you have a three-line example -- you're maybe exercising 5% of the optimizer? The current version of the C++ I was using comes in at around 50kloc. The Java and C# versions were a bit smaller, since once I stopped testing the platforms, all the new code only went into the C++ version, but it's a significant piece of work. I haven't seen any significant real application for which the theoretical benefits of Java (JIT's profile-guided optimizations, etc.) have really come to pass. You can write slow C++ code, but if you know what you're doing and instrument carefully, there's very little or no evidence that Java can be as fast on real programs.