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.-
I'm disappointed, everybody knows that when the going get tough FORTRAN get going
this post contain no useful information, no need to mod it down
The fact that they left out C# seems odd as well. It makes me wonder what the point was, really.
- Spryguy
There are three kinds of people in this world: those that can count and those that can't
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 the absence of evidence to the contrary, it's reasonable to assume that C#'s performance results would be about the same as Java's. Testing C vs. C++ vs. Fortran would much more interesting. (There is no such language as "C/C++" and it's really irritating when people lump them together, as many commenters on this story have.)
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
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.
Of course its going to be a C that wins. It's pushed close to the iron. C++ is for the careful, exacting personalities. I simply don't have the patience to use it on a day to day basis. Scripting is for the frenetic like me. If you pick a scripting language, you're selling out performance for keeping your rapid development and sanity. You can write beautiful safe stuff in C++ too. Use what you're comfortable with.
'...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 think that's the problem in a lot of systems today. Too many "average" programs are being written by too many "average programmers" - and this is why there are the problems such as memory leaks, etc. I feel too many have been spoilt by the ridiculous memory and processing speeds available in todays computers. What ever happend to understanding how functions perform and refining code to be lean and mean?
From the paper (section 6,E: Java Tunings) ". Note that Jeremy deliberately refused
to optimize the code further, many of the C++ optimizations
would apply to the Java version as well.'
--------------------------------------------- "In the end, we're all just water and old stars."
... most people are doing it wrong.
Good use of C++ fills a very small niche of people that want a relatively high-level language but care about a statement like "the compiler generates good code for this"... You want some of the properties of C, like being close to the hardware and generating straightforward machine code. Add to that some things that make OO easier. Add type safety. Add templates and function objects, which due to inlining gives you much better machine code than the typical C approach of a function pointer and a void* to provide such extensibility. What you have is kind of like "a better C". It has a lot of quirks and baggage, but with the proper understanding of the good and the bad it's really good for the sort of niche where these choices make sense.
The problem I have encountered is that bad C++ programmers are a dime a dozen. I don't think I've ever had any co-workers who would understand my previous paragraph. I know from reading books and papers and Internet that people who "get" C++ exist. The best I can say is that the vast majority of people using a C++ compiler don't know what they are doing. Instead I've met a lot of people writing C++ code who probably should be writing in Java anyway; they discard most of what C++ is good for, usually because they don't really understand it and they're trying to write Java-ish code in C++. The results aren't pretty.
In a way I agree with what Linus said in one of his famous emails, where some silly person was suggesting to rewrite git in C++. To paraphrase: Choosing C as a language is good even if the only thing it accomplishes is it keeps out the bad C++ programmers.
I guess the silver lining is that no two people can agree on what "good" C++ is. So maybe I'm just being too harsh in my assessment.
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.
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! Of course they never seem to have a good answer for why if this is the case all performance important apps (like games, audio software, etc) are written in something else or why Java linpack pulls like 750Mflops on a system where native compiled (from C) Linpack gets 41Gflops. However they are sure it is faster!
2-3Ghz Cpus have been out for ages, they are so fast, signals can't travel any meaningful distance within a single cycle - it makes a lot more sense to core up than to try and beat the speed of light. And you pointing out a core clock from 700 to 1Ghz in 3 years is good is actually just proving my point. 8-10 years ago you would expect a double up every 18 months, it's just not economically and physically viable to keep that race going.
And yes, they might have new instructions and they might be doing more per clock cycle, but you are by no means anywhere near the double up in efficiency *per* core that we used to see. The future is threaded applications - if you can't thread, go find yourself a nice FPGA.
Also, at no point did I *EVER* say you can't thread in C++ (please read peoples post and if you do, please don't put words in their mouth) - threading, and more importantly locking is vastly easier and safer to do in Java than C++.
Sure, if you write embedded applications, Java *might* not be the best option for you, but there are loads of processors that can handle Java in embedded settings - if what you are doing is something where microseconds matter, Java isn't your cup of tea, but for 90%+ of applications out there Java would be fast enough.
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.