Slashdot Mirror
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.'"
I thought this was common knowledge. Did anyone ever doubt that?
My blog. Good stuff (when I remember to update it). Read it.
RTFA and take a good hard look at what they compared it to: Java, Scala, and Go. This post is a complete non-story.
Wow, they compared a whole four languages: C++, Java, Go and Scala, of which, C++ is the fastest. Is this seriously a surprise to anyone?
Yes its true that C/C++ is generally faster than other languages, but when it comes to writing bug proof code, its not so good. Its very easy to write past the end of arrays and use bad pointers amongst other things. From a career point of view, C/C++ is bad. I should know, my main expertise is in it and I am struggling to find a job. There seems to be way more jobs for Java and C# programmers.
This jibes with "common sense" and the computer-language shoot-out
It's not useless. It's nice to see multiple studies with different approaches coming to the same conclusions.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
They didn't test BASIC? Lame...
-I only code in BASIC.-
Notice one of the comments pointed out that Borland Pascal was one of the fastest executing languages next to ASM. I remember that Borland Pascal (in 19991) executed almost 10 times faster than Borland C++ on a consistent basis on the same systems.
This only points out that tests need to compare apples and apples. I would be quite surprised if any C++ can execute a FFT as fast as my Leahy FORTRAN95.
If I was going to pick only one language to work with, it would probably be LISP, but Haskell comes a very close second. I like code that does exactly what I want it to do with no side effects.
There is much more to comparing languages than is reported in the article, including testing the language's suitability for a given task.
"The mind works quicker than you think!"
If pure speed is the sole criterion with tuning effort having zero consideration, wouldn't masterful Assembly or opcode be the fastest?
"Love heals scars love left." -- Henry Rollins
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:
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.
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.
Monstar L
It often turns out programmers are not as good at the assembly as they might think. I'm not saying a little hand tuned assembly isn't useful for some things but the "I can do better than a compiler," attitude usually has no basis in reality. Good ones are pretty clever at optimizing things. So maybe if you have an area of your code that uses a lot of time (as determined by a profiler, don't think you are good at identifying it yourself) and write a hand tuned in-line assembly version (maybe starting with the assembly the compiler generates). However you don't go and write the whole program in assembly.
C++, of course, is something you can quite easily write a very large program in, or operating system for that matter. Not quite as easy as a fully managed language, but perfectly feasible to deal with large scale and indeed it is what a large number of projects use.
That's because Java floats are not the same as C floats so compiler can't use the CPU's FPU to do the work for it directly. Java float types make more wider guarantees than C floats (that are usually just restricted to underlying hardware float). This is exactly the reason why Fortran beats C or C++ when it comes to numerical computation. The Fortran compiler can output faster code because language makes some guarantees and it's easier/possible to optimize it better.
As the island of our knowledge grows, so does the shore of our ignorance.
Talk to Java heads they'll tell you Java is already faster than C++. They can show you some contrived tests to demonstrate this too!
Take a look at the comments on http://jeremymanson.blogspot.com/2011/06/scala-java-shootout.html about the paper:
Here's one from the top:
The benchmark did not use Java collections effectively. It was generating millions of unnecessary objects per second, and the runtime was swamped by GC overhead. In addition to the collections-related fixes I made (as described in the paper), the benchmark also used a HashMap when it should have just stored a primitive int in Type; it also used a LinkedList where it should have used an ArrayDeque. In fact, after being pressed on the matter by other Googlers (and seeing the response the C++ version got), I did make these changes to the benchmark, which brought the numbers down by another factor of 2-3x. The mail I sent Robert about it got lost in the shuffle (he's a busy guy), but he later said he would update the web site.
Changes which, I might add, are still far easier for the average Java peon-on-the-street to understand than the C++ equivalents. The fact that the paper was comparing one program in C++ that had been optimized to within an inch of its life with another program, in Java, that had had someone spend about an hour "cleaning it up a little," makes for a grossly unfair comparison.
The fact that the "naive" (far more common) programs were all relatively the same speed was insightful.
You're special forces then? That's great! I just love your olympics!
BTW, a little extra digging reveals that the code was written by a C/C++ compiler writer who's a novice developer in Java/Scala. I'd say that the fact he did so well, comparatively speaking, in Java and Scala would be more noteworthy than the current takeaway.
You're special forces then? That's great! I just love your olympics!
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.
SJW n. One who posts facts.