C++ the Clear Winner In Google's Language Performance Tests

Paul Dubuc writes "Google has released a research paper (PDF) that suggests C++ is the best-performing language on the market. It's not for everyone, though. They write, '...it also required the most extensive tuning efforts, many of which were done at a level of sophistication that would not be available to the average programmer.'"

Comments

Common knowledge

[PitaBred]

I thought this was common knowledge. Did anyone ever doubt that?

Re:Common knowledge

[AuMatar]

There's a lot of Java-ites who claim that Java is just as fast. They're idiots, but they're vocal.

Re:Common knowledge

[martin-boundary]

It's reasonable to doubt that C++ is faster than ASM, and it's reasonable to doubt that C++ is faster than C. And if we're talking about hand tuned numerical libraries, it's reasonable to doubt that C++ is faster than FORTRAN.

Re:Common knowledge

[Unoriginal_Nickname]

Boost/0x shared_ptr can't handle circular references.

That's why people focus on memory management when they talk about C++: it's filled with 'gotchas' that will completely fuck you up if you don't completely understand everything you are doing. That's why so many C++ 'fans' hate automatic memory management. It's not because they're attached to the idea of manual memory management, it's because C++ forces you into a culture of paranoia and it's difficult to adjust to a world where the standard library isn't out to kill you.

Re:C/C++ faster but produces more bugs

[Erbo]

And, while C++ will always necessarily be faster to execute, there's no question that the other three languages will be faster and more straightforward to develop in. (Which, in general, makes them a net win, as programmer time is almost always more expensive than computer time, except in certain corner cases which should be obvious.)

Why? Three words: Automatic memory management.

No more worrying about whether you've allocated the right buffer size for your data...and maybe allocated too little resulting in an overrun screw, or allocated too much and wasted the memory. And no more forgetting to free that memory afterwards, resulting in a memory leak. You can write expressions like "f(g(x))" without having to worry about how the return value from "g" is going to be freed, allowing a more "natural" coding style for compound expressions.

I maintain that automatic memory management, while not great for code-execution performance, is probably the single biggest boon to developer productivity since the full screen-mode text editor. (Not saying "emacs" or "vi" here. Take your pick.)

Granted: You can retrofit a garbage-collecting memory manager onto C++...but that code will rob your C++ code of some of that enhanced execution performance which is probably the reason why you chose to develop in C++ in the first place.

Java is fast

[wurp]

In some situations Java will be faster than unoptimized C++ - JIT compilation will do enough of a better job than vanilla C++ to make the difference. In general, C++ will clearly be faster. However, I think what most of the people you're qualifying as idiots get up in arms about (rightly) is the assumption that so many programmers seem to make that Java will be many times slower than C++. That's (usually) just wrong.

In particular, here's what Google's analysis had to say about it on page 9:

Jeremy Manson brought the performance of Java on par with the original C++ implementation

They go further to say that they deliberately chose not to optimize the Java further, but several of the other C++ optimizations would have applied to Java.

For most programming tasks, use the language that produces testable, maintainable code, and which is a good fit for the kind of problem you're solving. If it performs badly (unlikely on modern machines), profile it and optimize the critical sections. If you have to, write the most critical sections in C or assembly.

If you're choosing the language to write your app based on how it performs, you are likely the one making bad technical decisions.

Re:Java is fast

[Splab]

For me it doesn't matter which language is faster, I'm using the one that solves my problem the fastest (e.g. shippable product fastest) and right now, Java is the main player for me.

Also, since our CPUs aren't getting any faster, we need to use languages that makes threading easier the safest way and on that topic, Java is miles ahead of C++. (Java used to have an utterly broken threading model, but these days it works [tm]).

Re:C/C++ faster but produces more bugs

[Vintermann]

So, you never have any memory leaks? Or double frees? Convenient for you that you're an anonymous coward, because it would probably be a quick issue to call you on. I've met some extremely careful coders (among other things, the developer of one of the first projects to reach zero defects in Coverity's open source scan effort), and none of them make such ridiculous statements.

Not a language shootout....

[antifoidulus]

There is no such thing as a real "computer language speed test", this is really a test of compilers, environments, VMs/interpreters, and environments. The first question that has to be raised is of course when the program is running on hardware, what "language" is it written in? The hardware sure doesn't give a shit. You can compile almost any language into native code, including VM driven languages such as Java and PERL. Now granted TFA states that they ran their loop 15k times to try to minimize the effect of the load time and run as much JIT compiled code as possible, but that's still not the same as compiling it directly into native code.

Which brings up another point, are they really testing the "programming language"(which is just a bunch of specification and usually implementation hints) or are they testing the compiler/environment they are on. Code compiled with GCC and ran on a Linux box will probably perform differently than code compiled with Microsoft's compiler running on Windows which will behave differently than code compiled with LLVM/CLanger running on OS X...... You can probably say the same thing about Java compilers, I'm assuming they used the Oracle reference javac, but there are other Java compilers out there. How do you test the speed of the "language" when so much of that performance depends on the compiler and environment you are running other?

Which leads into my final point, when does a language stop becoming something written in that language? Although not tested this time, probably the best example of this point is Ada. Anyone who has coded in Ada knows how insanely strict it can be, it constantly does things like bounds checking to ensure that data stored in subtypes is within the bounds of those types. However on most Ada compilers most of these checks can be disabled with just a couple compiler flags. Obviously the resulting code is going to be faster than if you kept the checks in, but does it stop becoming Ada at that point? You can make a similar case for Java and JNI. JNI is completely legal in the Java language specification, but when you use JNI does your program stop being a Java program? Could you have optimized it further by using JNI?

This is merely a test of whatever compilers/VMs they used in whatever environment they ran the code in, nothing more, nothing less.

Re:Business is different

[serviscope_minor]

It's really painful to write C/C++ code

That's because if you treat C and C++ as one language, then you suck as a C++ programmer.