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.
This had been much more fun if there had been more languages and compilers benchmarked. Really interesting read though.
HTTP/1.1 400
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.
FTA: "All languages but C++ are garbage collected, where Scala and Java share the same garbage collector."
That's got to play a factor here.
There's no -1 for "I don't get it."
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
What was even the point of comparing these 4 vastly different languages? Java and Scala both run in virtual machines so it's obvious a native compiled language is going to beat them out. C++ is a very mature and popular language with a heritage going back to an even more mature language, so obviously it'll beat out just about anything. I think the Go language is pointless to being with, but this would have been much more interesting if they did some benchmarks comparing it to some other compiled languages like Pascal, BASIC, FORTRAN, C/C++, or D just to see where it stands in the group. This just reeks of someone coming up with some busy work to make it look like they have something to do at Google.
A slower language just means you need to buy more rack space. A more expensive development language (like C++, which needs more skilled coders, more debug time, etc.), means that you need to buy more developer man-hours. As far as the business world is concerned, I thought everyone had come the conclusion already that as far as business apps go, C++ isn't generally worth it.
Leave C++ for the games, the operating systems, and the frameworks that the higher level languages run on. But since everyone already knows this, TFA is kind of pointless.
They only benchmarked 4 languages.
people should write dissertation on this..
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.
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?
And they test against only three other languages? What kind of BS is that?
So what about C, Fortran, Ocaml, CL, Haskel? Last I heard C & Fortran were every bit as fast as C++ (if not faster) and the other three can produce very fast code.
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."
To a great extent, this is not about the superiority of C++ compilers, but about the limitations of the JVM as a compiler backend (and possibly, if I read it right, some problems with the garbage collector). Go is still too much under development to be a realistic comparison point for high performance code.
For example, one of the C++ tuning optimizations that they used was changing a linked list of pointers to basic blocks to a vector of basic blocks. This eliminates a level of indirection, requires fewer allocations/deallocations, and probably has better caching behavior. But the JVM cannot even produce the same representation due to its incapability of expressing a flat sequence of records/structs (unlike, say, the .NET CLR). They were also using some handcrafted internal Google data structures for tuning and some fairly low-level optimizations.
I doubt that the results would be as lopsided if the comparison occurred with a language with a more versatile IR and a mature backend (such as OCaml).
Assembler is by far the best performing language. But most of the time, Java performs well enough with modern hardware, so that performance becomes a moot point. As the article mentions, Java is the easiest to implement. It also has the advantage of being cross platform, something which the article doesn't address.
... 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.
If you speedtune c++ enough it will resemble pure c. In that case you want c to get rid of the annoying c++ ABI and for a further increase in speed.
The cases in which performance is critical, are getting less and less, now that hardware is getting faster and faster. Not strange that Microsoft is focussing on JavaScript and HTML5. It seems that at the moment the greatest effort in performance improvement is put into JavaScript.
I don't know about that, maybe it was faster than Borland C++, but I did a lot of work (disassembly) on Borland Pascal compulation units and executables back in the day, and the code was horrible. HORRIBLE. Didn't even have the most basic peephole-optimizations (though someone wrote an external application to do that). It was fast to compile though, due to being one-pass, but that right there sacrifice optimizations.
So if TP/BP was faster than BC++, it was only because BC++ must have been even worse than I can imagine.
Belief is the currency of delusion.
trollfood / fanboi-food post is obvious debating the effectiveness/awesomeness/speediness of a programming language is like saying "apples are better cuz oranges have hidden pips"
From the research paper:
"In all implementations, we use the default, idiomatic data structures in each language, as well as default type systems, memory allocation schemes, and default
iteration constructs. All four implementations stay very close to the formal specification of the algorithm and do not attempt any form of language specific optimization or adaption."
"We believe that this approach highlights features and characteristics of the languages and allows an almost fair comparison along the dimensions of source code complexity, compilers and default libraries, compile time, binary sizes, run-times, and memory footprint."
From the research paper:
"At time of this writing, the cpp_pro version depended strongly on Google specific code and could not be open-sourced."
We aren't given the source code so I can only speculate, but the above comments don't seem to jive. If you are trying to only use default libraries, types, etc of the languages and not use language specific optimizations or adaptations, then I have a little trouble coming up with how you could have "Google specific code" upon which the C++ improved version depends.
Nope, C++ certainly not for everyone. But the most powerful tools rarely are.
/* No Comment */
You mean suspend/resume? That was deprecated like 10 years, but functions required to do it right were in from the beginning (since 1.0).
Many talk about time to develop, and certainly C/C++ sucks in that capacity. And many talk about code complexity and liklihood of bugs due to memory management, and certainly there's much to be said there too. But C/C++ fails me in one very simple business category: code robustness.
Every project I work on has clients doing one very important thing -- turning the entire thing upside-down and backwards three times. In C/C++, I'd get to start from scratch every time. In Perl, I get to shuffle a few lines of code to invert a feature, and that's it.
It's really painful to write C/C++ code in a flexible manner for future arbitrary upgrade. And that's what I need in order to run my business. The other speeds can be made up by throwing money at additional hardware. I can't tell a client that it'll take months to make a decent upgrade, nor charge them for that much time.
Many talk about time to develop, and certainly C/C++ sucks in that capacity. And many talk about code complexity and liklihood of bugs due to memory management, and certainly there's much to be said there too. But C/C++ fails me in one very simple business category: code robustness.
Every project I work on has clients doing one very important thing -- turning the entire thing upside-down and backwards three times. In C/C++, I'd get to start from scratch every time. In Perl, I get to shuffle a few lines of code to invert a feature, and that's it.
It's really painful to write C/C++ code in a flexible manner for future arbitrary upgrade. And that's what I need in order to run my business. The other speeds can be made up by throwing money at additional hardware. I can't tell a client that it'll take months to make a decent upgrade, nor charge them for that much time.
In the paper they write, that they used the JVM-Option "-XX:+CycleTime" alongside others. I couldn't find any reference on what CycleTime does, nor does my Oracle JVM 6u24 recognize it. Does anybody have an idea, what this option is for, and if it's actually available in regular JVM builds?
Lowest-level language with careful tweaking yields best performance. Film at 11.
" Functional languages should excel at this, they have been ruling the program transformation/analysis space for a long time."
I think the key is homoiconicity, not functionalness. Prolog isn't a functional language, and it's mainly used for domain specific languages/one-off compilers.
Google has released a research paper (PDF) that suggests C++ is the best-performing language on the market.
No, they didn't. They compared four languages (C++, Go, Java and Scala) using a single algorithm, and two implementations (initial and improved) per language. Out of those, the optimized C++ turned out to be the fastest and the least memory hungry, whereas the improved Scala version used the least source code, and the improved Go version compiled the fastest.
None of this allows generalization to "best-performing programming 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.'
This is a very important point. If you are Google, you probably have developers who can do this kind of tuning, and you will probably benefit from it (the developer effort is expensive, but inefficient software may well be more expensive at Google's scale).
In general, though, what you want to consider is not only the best performance that has been produced by the world on a single problem, but also the performance on different problems, the variation in performance between implementations, the average performance, and the development time.
In 2000, Erann Gatt (now Ron Garret) published a paper (PDF) that showed the results of comparing 16 implementations written by 14 programmers, in C or C++ (lumped together), Java, and Common Lisp or Scheme (lumped together). These results show that the fastest programs were written in C or C++, Lisp produced the fastest programs on average, and offered the least variation in performance. Lisp also offered the shortest development time on average.
Of course, this is old data. If anyone has performed a similar study more recently, or including different problems to be solved rather than a single one, I would be very interested.
Meanwhile, the Computer Language Benchmarks Game compares many language implementations across several different tasks, with multiple programs for each task, and shows that the results differ depending on exactly how you measure.
Apparently, if you want the fastest programs, you should go with C, C++, Ada, ATS (Fortran, Common Lisp, and Python also produced fast programs, but weren't as good on average). If you want short programs (which may be expected to correlate with short development time), you might want to go with Ruby, Python, Perl, Lua, or JavaScript. If you want short development time, but also reasonable performance, then Go, Scala, or Haskell may be good choices (or you could go the time-tested route of writing what you can in rapid development languages, and the parts that need to be fast in high-performance languages).
Please correct me if I got my facts wrong.
To me the results of the Scala implementation are more noteworthy than the comparison between C++ and Java. If I read The Fine Paper correctly the Scala version is more concise, faster and has a lower memory footprint than the Java version. Since both compile to Java bytecode and run on the same VM this really is remarkable.
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
Surely assembly would be the highest performing language, while also requiring the most extensive tuning efforts and a level of sophistication not available to the average programmer...
More importantly tho, would be to know which language provides the best balance between performance and work required?
And ofcourse another thing to consider, is how often the code will run.. Not much point saving an hour writing it, only to waste 500 hours of cpu time running it.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
I think the biggest problem with Java is the memory bloat. A lot of the developers that work with Java have a very limited understanding how things work under the hood. This usually leads to programs that include references to "good to have" packages/frameworks that contain some functionality they need which in turn leads to memory bloat. If you then have a java-program that needs to run in multiple instances you don't gain the functionality of one memory-image many processes most OS's support. (One of the core-features that Dalvik has if I remember correctly).
Since Java have GC a lot of Java-folks seems to think memory use isn't something you should care about since the "GC" can handle it for them. This leads to bad coding-practices. No matter the language you should always know the scope of an objects life.
IMHO it doesn't matter what language you are using as long as you know what you are doing. Java often get "bashed" from C/C++ programmers but I think that's because Java as a language has a lower threshold with regarding to prerequisite knowledge about CS and is easier to learn, which produces programmers that thinks about computers as a mysterious black box that "just works (mostly)" and the code reflects that in functionality and poor performance.
--- Reality doesn't care about your opinions, it happens anyway and if you are in the way you'll get squished.
a-choo - excuse me. So a Toyota Camry is the best all-round performer of vehicles on the road today, But if you want super performance, buy a Ferrari, and if you want to haul freight, buy a Mac truck. Really? Wow. Could a more pointless generalization be possibly made about programming languages? What it really points to is that Google have now totally lost the plot in their love affair of their own cleverness. Hello Borg Mk II
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.
The closer to writing in pure binary the more efficient your code potential is. Im sorry for the guys who invested so much time mastering Java and still have hopes to become world renowned programmers.It is no wonder why embedded developers are in such high demand.
What, no INTERCAL? It could have blown away the competition; it has "COME FROM"!
The paper doesn't talk about using:
1. Custom allocators (stack and pool based)
2. Move semantics
3. Modern C++ idioms such as expression templates
I believe if these were used, the performance would have even better and left the rest "truly" in the dust...
Arash Partow's Philosophy: Be a person who knows what they don't know, and not a person who doesn't know.
Please show me how to implement Macros -proper Lisp-style macros- in C or C++ so that they are available in standard C (or C++).
Thanks.
Bad analogies are like waxing a monkey with a rainbow.
Waiting for the same performance test between french, english, german and spanish. God, that will be interesting! And almost as useful.
Is that a challenge Google?
The competition was Java, Scala and Go. Quite a limited set and definitely missing C for one. And unlike C++ optimization, optimizing C is something you can do without understanding details of the compiler. So I will definitely stay with C for everything that has high performance needs, even if I have to do the OO aspect myself.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
'While that effort is an anecdotal comparison only[...]' .. Come on. The title is about loop recognition, not about finding the fastest language on the market. There's no such thing. Depends on what your objectives are and the application type.
The paper compares an heavily optimised version with a version in another language with no optimisation?
This is what matters for me. I want my program to have acceptable speed just by writing it in the most straightforward way. Squeezing out the last bit of performance isn't usually necessary, but 10x slower is also unacceptable. Many people defend slow languages by saying that premature optimization is the root of all evil, but in C/C++, you simply don't need to do ugly premature optimization in most cases, since the program often runs fast enough as long as all best practices are followed.
C++ seems to be useful in most cases as long as all developers know it well (using correct data structures, not copying large objects around unnecessarily, etc.), including important libraries in STL and Boost.
C is also good with the right libraries such as glib. It is more verbose than C++ and manually freeing all the memory can take a bit of developer time, but it is also easier to learn.
Fortran 90 is even easier, but is only suitable for numerical programs without complicated data structures. Java is also easier and fast enough, and may be a good choice for non-numerical work (numerical programming is still a bit awkward).
Scripting languages are, for the most part, still too slow for non-scripting work. Sure, a program in these languages can be made faster by writing some speed-critical parts in C, or by writing the program carefully so that my particular implementation can optimize it well, but this will usually take more effort and make the program harder to maintain.
The benchmark imposes the restriction of using "idiomatic constructs". But that's just what you wouldn't do if you had to optimize a performance critical section by hand.
Nevertheless, for deciding among those for languages, the conclusions are probably still reasonable. The verbiage before just serves as an alibi.
What the paper really says is "we don't want to use Go"; there is probably pressure to do just that inside Google.
Seems to me they are. For one, their MHz are pushing up. Not by leaps and bounds, but they keep improving. Take a look at the last three generations of mid-range quad core Intel chips ($300ish):
--Sandy Bridge (current) goes from 3.4GHz to 3.8GHz depending on core load (meaning it changes speed dynamically).
--Lynnfield goes from 2.93GHz to 3.5GHz depending on core load.
--Yorkfield 2.67GHz, no boosting.
Yorkfield came out in March of 2008, Sandy Bridge in January of 2011. So in in about 3 years base clock rate has gone up 700MHz and beak clock rate over a GHz.
Now that aside, the CPUs are getting much more efficient per clock. You find that each generation has significant per clock gains over the last one. Same code, same MHz, faster execution.
Then of course there's new instructions. AVX in particular really boost Sandy Bridge's floating point speed.
Add it up, they've increased in speed a lot.
I agree that threading is important, as I noted all this is on quad core processors, but the idea that you can't do threaded code in C++ is silly. The most simple demonstration against that is all the PC games out there. Nearly all of them are done in C++ (Visual C++ to be specific) and these days they are all multi-threaded. For more intense threading in C++ apps, have a look at audio software and plugins.
If your products are all ones where speed is not an issue, and there are plenty that are not, and where the overhead of Java (not so much things lime memory, more like administration in that Java wants to update all the time and you have to have it installed before you app works) are ok then wonderful. However there are a lot of applications out there where performance matters and it still seems to be that languages that generate native code, like C++, do a better job.
Even if I prefer Fortran to C due to the ease of handling matrices, I haven't seen any case where Fortran is faster than C. Therefore "when the going get tough FORTRAN get going" cannot be due to speed. Or, any links to benchmarks to back it?
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!
I haven't used Apple's new compiler, but under Leopard (10.5), using GCC, the actual machine code that is produced for objective c is *awful*. Constantly re-using the same registers, putting them away, bringing them back... it's as if the compiler uses a one-type-of-each-register model. Speaking as an assembly programmer, for any particular procedure that I looked at, I could have *trivially* whipped GCC's ass back into the stone age for execution efficiency.
Apple says the new compiler produces better code, and all I have to say at this point is that shouldn't have been difficult to do, because obj-c -> gcc sucks ass.
I've fallen off your lawn, and I can't get up.
No they're not, they just better understand the argument than you do apparently, and Google's conclusion doesn't disagree with them.
I think everyone agrees C++ can theoretically perform faster, but as Google notes you need to perform a lot of optimisations by hand which requires a lot of time, and a high degree of skill to perform.
The argument for Java is that it performs as well as C++ when you either do not have the time to do these optimisations, or do not have the skill to do these optimisations. There is a further argument that in this day and age there is no point doing such optimisations because the performance edge is small enough to be not worth investing the time in.
The fundamental point is that an extremely skilled developer, with no deadlines, will always be able to produce better performing code in C++ than Java, but:
- Time is money
- Skills cost money
- The code may be harder to read and maintain due to optimisation
- The software will be inherently more prone to developer errors that can lead to security vulnerabilities
So in the real world C++'s performance advantages are more often than not, irrelevant. That is, the real world doesn't really care about performance penis waving C++ developers 99.99% of the time, because they'd rather have code that's portable, easily maintainable, has a smaller potential attack area, and is developed in a cost effective manner. It is these real world factors that give Java the edge, and under these real life factors that C++ struggles to compete. That is why Java, and other languages like C# and .NET have eaten massively into C++'s marketshare in the last decade.
The arguments implying C++ is the one true language are produced only by those lifelong code monkeys who never got passed that role because they simply never understood the practical or business side of things, and without a doubt whilst they can write great code that performs well, there will be inherent disadvantages- their code will over time simply by nature of humans inability to be 100% consistent in avoiding mistakes be more prone to security vulnerabilities, will be less maintainable, and will cost more to develop.
It's really about the best tool for getting the job done without worrying about some performance gain only noticable to a user if they see the sub-second comparison metrics listed for them, and I'm glad to see others point that out too- knowing when to and not to use a certain tool is the sign of a great developer, not dismissing dissenting opinions as vocal idiots without apparently even understanding the argument they make.
Why would anyone expect average programmers to write well performing code in any language?
My conclusion is that the performance advantages of C++ are easily offset by its ability to confuse the programmer. C++ is arcane and complicated; Java is more limited; Python is a lot cleaner. If you know exactly what you're doing, then C++ can be the fastest option, but in real-life situations, with deadlines and average programmers, don't go there.
I can only assume that this is a non-reviewed whitepaper rather than a journal paper, because the results are useless. They fail to specify the compilers used, the compiler options, the target CPU (thus making the binary size comparison meaningless). The conclusion that "C++ wins out by a large margin" can't be supported unless you take a representative sampling of compilers for each language. Heck, they haven't even used gcj in the comparison (and I think gcc vs gcj would be a much more interesting comparison since it'll be more-or-less the same backend).
I've read the entire thread, and one common complain about c++ is manual memory management.
So, my question is this: why don't people use smart pointers? boost has the class boost::shared_ptr which works with lots of compilers, and the upcoming c++ will have std::shared_ptr.
With smart pointers, there is no need to manage memory manually. I've written whole apps (130-150Kloc) without a single delete statement and without a single memory issue by using smart pointers.
Look at performance critical applications: signal processing, image processing, graphics, data base implementation, operating systems. Any time performance is high on the list people pick C, C++, Fortran, and sometimes ADA. Compilation is the only feasible choice. One thing that compilers give is the ability to tune the algorithm based on real execution profiling. If you don't compile at some point you will run into language implementation decisions that are out of the coderscontrol, and you will hit a wall. This means more work, but greater effort gives better results. If other things like programmer time or ease of modification are important then non-compiled languages may be better. One size does not fit all.
Why is Snark Required?
Alex Trebek: This language has the best performance. It's almost "D".
Watson: What is JAVA?
Is this actually news worthy? A better question is: which one allows programmers to perform better? I'm not just talking lines of code, but rather how much time is spent developing in general. I guess that would be hard to measure but it would make for a far better research paper.
After teaching programming for a while now, it's my very strong suspicion that far more performance bottlenecks are caused by programmers who don't even understand what time and space complexity is, than are caused by competent programmers implementing in one language over another.
For instance, I just set a scripting assignment (to be completed in bash 3.0, which lacks associative arrays) which asked students to process syslog files and report how many times different applications appeared in the logs. Some students did this by repeatedly using grep and wc over the entire log file, and wondered why I deducted marks when it took a minute to run on moderately large logs.
God help anyone who uses a program they've written.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
Additionally - You're right on that, because it also held true into later years (1997-1998) when, in of ALL places (a competing trade magazine), Delphi/ObjectPascal 7, did great on a series of tests in VB Programmer's Journal Sept./Oct. 1997 issue "Inside the VB5 Compiler Engine"!
That's where Borland Delphi (Object Pascal 7 really) knocked the chocolate out of BOTH VB & MSVC++...
Especially in the MATH & STRINGS tests, Now - Mind you, EVERY PROGRAM WORKS ON MATH & STRINGS!
(However, I don't *think* I have to tell YOU, that - especially if you've been coding since then, but, that's for everyone else's benefit who doesn't code).
Delphi nuked VB right outta there, hugely (Java too of course), AND MSVC++ TOO (by a couple orders of magnitude).
In fact, it took "1st place" in 2-6 tests given (pretty much "even split" w/ C++, as far as wins, but MUCH better in results overall):
RESULTS:
---
Strings (Delphi - by a 50%++ margin over C++)
Math (Delphi - by a 50%++ margin over C++)
TextBox form loads (C++ won this, by .001% margin over Delphi only)
Native-to-Language Graphics Methods (C++ won this, by 1% margin over Delphi only)
API Graphics Methods (C++ won this, by .5% - SMALL MARGIN)
ActiveX form load (VB won this, only 1 it did)
---
Additionally & Lastly:
Where Delphi/Object-Pascal won, it won by GIGANTIC margins... Especially in MATH & STRINGS!
(IIRC, It's because of how Pascal handles strings iirc (C/C++ read "right to left" whereas Pascal reads "left to right", or something along those lines)).
In fact - It's the "why" of WHY I started using it back then, over both VB, & MSVC++, for years for personal AND work projects (where it was allowed, most places were MS shops)
APK
P.S.=> Thus, you can see how Pascal's a great language for speed/performance... even back in those days!
...apk
http://developers.slashdot.org/comments.pl?sid=2239636&cid=36448994
And, the compile speeds? Due to something I noted in how Pascal handles strings vs. C/C++... see that link above.
APK
We all know Google and Microsoft Bing are internally implemented in Brainfuck. We don't they simply admit it? They're trying to hide that fact by publishing language-comparison mumbo-jumbo while using the specially crafted Brainfuck processors to keep their domination.
Just that you will go mad figuring out the Hollerith field way of specifying strings and will never complete the project. But if you actually got the code to compile and run, Fortran would be the most awesomest language.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Wait, wait, wait ... "[Google] implemented a compact algorithm in [...] C++, Java, Scala and [...] Go" and C++ was the 'best performing' OF THOSE FOUR. Not best on the market, best OF THOSE FOUR. To which I say ... of course it is.
Now, you wanna go ahead and put C and ASM in there? C++ won't make it.
So they ran a test between two statically-compiled native-code languages and two dynamically-compiled bytecode languages, and then seem surprised when one of the native-code language wins?
I'm also noticing a marked lack of C# (not something I'm personally a fan of, but nothing if not a mainstream competitor to the languages listed) and Python (another language that gets "used for real stuff" inside Google) in the test. Why is that? Not that I'd expect Python to do very well in a performance test against languages like these, but it still seems an odd omission.
Google are currently preparing a paper comparing Linux and Windows... Linux will win on technical grounds, but Windows will get props for nice icons and user friendly dialogs.
PHP (easy/fast to develop in and maintain) on a modern chip.
-or-
ASM/C on an old chip.
My point - as chips get faster the benefit lies in the code creation/maintenance/portability & ease of use with high level languages.
Low level languages like C++ are highly optimized for the current computing environment. But they are hard to program. The future belongs to programming environments that are.
1) hard for a programmer to understand because they are data flow or multi-processing or highly data-local (cache optimized) or syncronous (GPU).
2) the environment may be unknown or variable not fixed. you may not know where your program will be executing from day to day or what the specs of the machine are.
Languages good at this don't exist yet. And we have not even begun to tap functional programming's potential.
The other problem with C++ is it's very easy to make logical errors in.
Some drink at the fountain of knowledge. Others just gargle.
If the C++ needed extensive tuning beyond the abilities of the average programmer, why not also test against hand-tuned ASM. I can't think of many instances where C++ would beat it if the difficulty of coding were ignored as it was for C++
One thing that struck me in the paper is just how much of the need for C++ tuning seems to arise from complexities of the standard library components, or just of C++ itself. I have to say at this point I prefer to work in C, with libraries I understand well.
Besides, different languages are better at different things. I bet Assembly is a heck of a lot faster than C++, but I wouldn't want to try coding many of the applications that use C++ into Assembly.
... eventually; often when its too late to do anything quick, easy or cheap to make it better.
From personal experience, most of Google's developers don't know C++, including a great many who claim the do but really don't. I guess this is a problem for Google.
Given the number of Googlers involved with producing this article, I'm more surprised by them not using TeX quotation marks correctly than the result of the competition. (Not to mention using crappy tables with way too many ruled lines which do nothing to aid understanding of the organisation of the tables.)
Experience frequently shows that people that overlook such details writing an article will often by nature be weak C++ team programmers. More than with most other languages, good C++ coding demands someone who is intrinsically observant, obsessively perfectionist and aware of often obscure side effects and implications of everything they write. This is obviously important on the most basic level so that they don't make mistakes, but even more important that they understand how other people could misinterpret complex code and algorithms and potential consequences.
It is this last level of empathy that is the sign of great C++ programmers vs. the good or clever. "Clever" solitary programmers (such as some of those drawn to perl) are in fact the worst to have in C++ team programming scenarios where their desire to demonstrate their own ability often ends up with some over-templated prematurely optimised nightmare which is then left as a trap for someone seeking to modify it later on.
Systems that require "tuning" for good performance are inherently bad. Think about old TV sets that had fine tuning knobs. The knob was only there to compensate for unstable internal oscillators. In electrical engineering terms you have a high Q system. A high Q system means that small perhaps uncontrollable changes in inputs causes large changes in output. In software terms small changes like a compiler revision, processor change, etc can cause big changes in performance.
The fact the C++ programs can and perhaps must be hand optimized by humans is a sign of the immaturity of the technology. It is not a benefit but a disadvantage.
I fail to see anything looking over Java's spec that doesn't match to the capabilities provided by Intel and AMD's SSE2 implementation. So what, precisely, is it that Java is doing that keeps it from using the massive amount of FPU power present on modern processors?
Also if that is a problem Java has, well then that is a major performance issue right there since most performance intensive apps these days are FP heavy. When people start talking about wanting to crunch a lot of numbers, they are usually talking FP. 3D graphics, games, audio processing, EM simulation, etc you are talking FP heavy stuff. If Java is going to run at about 2% speed, that is a real issue.
The lack (by choice apparently) of operator overloading cripples this language for any scientific application. They say they chose to deny operator overloading because it produces 'obfuscated' code. I would reply with something along the lines of:
c++:
Matrix A,B,C;
Matrix D = A*A+B/C + A*C
Java:
Matrix A,B,C;
Matrix D = A.mult(A).plus(B.div(C)).plus(A.mult(C))
Although my Java is pretty rusty, i'm pretty sure the more obfuscated code is definitely not the c++! Now try moving this to a massively parallel environment.
Let's not forget that Java strings are more similar to Pascal than to C. A string in Java is an object that encapsulates a char[], a start index and a length. So for example, taking a substring from i to j is O(1) in time and memory for Java—it just returns a new String object with the same char[] but a new start index and length.
Are you adequate?
The interesting part is not that C++ is faster, but that it was quite comparable to Java and only became much, much faster after several Google engineers optimized it!
Let this be the final evidence in what I call the "great C++ conspiracy":
Good coders make good code. If you want the fastest code you have to go beyond compiler optimization. You need programmers who are not only at the top of their field, but can dream in code. So, if you want a language to reliably produce the best results, you have to make sure that it attracts the right kind of people and kills the weak.
A language that only works for people who have given up any regular sleeping patterns, social ties, and hope. A language that will cause any sane person to stab themselves with a null pointer. A language where operators can be overloaded, and anything could mean anything else in a different context. Beautiful if done right, but treacherous and deadly to the uninitiated. What better, than to design a language that is the coding equivalent of walking through Mordor!
I know it's aweful to actually RTFA. but, the Java tuned implementation actually reached the speeds of the original implementation in C++, but then the C++ was tuned further. Moreover, the dev (Jeremy) refused to apply additional optimizations to the Java implementation (the paper does not say why) but the authors did say that the C++ optimizations could be applied to the Java implementation (assuming that it would make the Java implementation even faster).
So, not sure why the hate has to go on about 'Javaheads', but most of the comments found here about Java speed are based on misinformation and causes the Java advocates to come out and speak up about the truth.
For when your only value metric is run-time speed.
Of course, if you actually have to take into account stuff like speed of adding features to the system, or skill-level of available programmers, or robustness, you're probably better off using anything else. Fortunately, most software is not speed-critical and you can use more reasonable programming languages.
C++ is a good language... but only for the limited circumstances in which it excels. Otherwise, the overhead entailed in coding in it isn't worth the cost.
That is all.
'...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.'"
Actually, if we define "programmer" to be someone who can perform such tuning then it's 100%. Those who cannot perform such tunings would be "wasted protoplasm".
String parsing goes right to left in C/C++ & the reverse in pascal iirc/afaik, AND, function call parameter passing on x86 is different in them also, ala:
(PAY ATTENTION TO THE BOLDS BELOW TO SEE WHAT I MEAN)
pascal: Based on the Pascal programming language's calling convention, the parameters are pushed on the stack in left-to-right order (opposite of cdecl), and the callee is responsible for balancing the stack before return. This calling convention was common in the following 16-bit APIs: OS/2 1.x , Microsoft Windows 3.x, and Borland Delphi version 1.x.
register: An alias for Borland fastcall.
stdcall: The stdcall calling convention is a variation on the pascal calling convention in which the callee is responsible for cleaning up the stack, but the parameters are pushed onto the stack in right-to-left order, as in the _cdecl calling convention. Registers EAX, ECX, and EDX are designated for use within the function. Return values are stored in the EAX register. stdcall is the standard calling convention for the Microsoft Win32 API and for Open Watcom C++.
Microsoft fastcall: Microsoft or GCC __fastcall convention (aka __msfastcall) passes the first two arguments (evaluated left to right) that fit into ECX and EDX. Remaining arguments are pushed onto the stack from right to left.
Borland fastcall: Evaluating arguments from left to right, it passes three arguments via EAX, EDX, ECX. Remaining arguments are pushed onto the stack, also left to right. It is the default calling convention of Borland Delphi, where it is known as register.
---
* And you're right, afaik, about null terminated strings as well as pascal strings carrying their length 'built in'.
APK
P.S.=> I don't/didn't know if you recall "stdcall" vs. "pascal" calls also, but that's another diff., per all of the above, in function calling parm passing too!
... apk
I am PRETTY SURE you can get the length of a C string ahead of time, by using a simple trick:
That's by setting up 2 pointers to vector thru it!
Both start @ "zero-th", & the second is ALWAYS DOUBLE THE FIRST...
(You need to 'err-trap" this, because the error on the 2nd pointer failing to advance, is what gives you the length of said string (by doubling the first "1/2 sized pointer")).
APK
You're describing "shortstrings" here:
"at least in Borland Pascal the maximum length of a normal string was 255 characters for this reason" - by gay358 (770596) on Wednesday June 15, @12:50PM (#36452342)
Also, so you know?
In 32-bit Delphi @ least??
You could use a compiler directive to force shortstrings vs. std. strings, by placing it around various blocks in your code:
E.G.: (1st one turns OFF normal strings, 2nd turns them back on)
$H-
Your function or procedure would be here...
$H+
OR, by declaring the variable used as a type shortstring, either globally, or inside the function/proc using it.
var
StringVar : String;
SmallStringVar : ShortString;
APK
P.S.=> Iirc, the "advantage" was one used the heap, & the other, the stack (but, I am getting "dim" on this one here, as it's been quite a few years since I coded any Delphi, 2006 iirc (used to be my "fav" too, & for many years!))... apk
Your average programmer either isn't doing C++ or won't be for long...
That is not to say its a bad language, but its like giving a kid a table saw or oxy acetylene torch. Sooner or later something bad is going to happen. Made worse by the fact that every single person doing C++, thinks they are an expert and proceed to use every obscure feature at the same time.
Jeremy Manson brought the performance of Java on par with the original C++ version. This version is kept in the java_pro directory. Note that Jeremy deliberately refused to optimize the code further, many of the C++ optimizations would apply to the Java version as well.
So they intentionally optimized the Java version much less than the C++ version, and they know the Java version could be sped up by applying the same optimizations they used for the C++ version. And (who would believe it?) the C++ version came out faster than the Java version! What a surprise!
Truly nothing to see here. Please move along.
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."
Compilers here... much as yourself on function calling conventions:
"It has been so many years since I last programmed using x86 assembly, that I didn't remember all the differences between Pascal calling convention and C convention." - by gay358 (770596) on Wednesday June 15, @04:58PM (#36455160)
I understand fully, hence, in my init. reply which you are noting now on stringwork (and in my subject line above now?) - I did state "iirc" & "something along those lines", indicating not TOTAL surety on my end!
In fact, quoting myself again from it:
"(IIRC, It's because of how Pascal handles strings iirc (C/C++ read "right to left" whereas Pascal reads "left to right", or something along those lines))." - by Anonymous Coward on Wednesday June 15, @09:00AM (#36448994)
So, you're probably right (now that I think about it) below - I can "err" or be unsure, as I was above...
Above ALL else: I don't design compilers, I just use them!
I get hazy too (getting old here, 48 yrs. old almost now). I never thought I'd say that, but... I think it's starting, lol!
---
"However, as far as I know, this has little to do with parsing source code or strings. And as ar as I know, the typical way to parse strings in C (eg. strtok) and Pascal tends to be from left to right (source code, after it is tokenized is different matter). However, parsing programming languages is often done from right to left, but this depends on the implementation of the parser. " - by gay358 (770596) on Wednesday June 15, @04:58PM (#36455160)
Again - You're probably the one who's correct on the strings parsing, especially now that I think about it...
I just KNEW there were things that PASCAL does, left-to-right (function call parm passing, tokenizing, etc.) that C/C++ don't.
* Anyhow - good discussion & review for me @ least! Thanks...
APK
P.S.=> Heh, something you MAY be "interested in" or find pretty cool possibly:
I put up a "little trick" in my other replies to you that pretty much does what a PASCAL "sizeof" does, in regards to finding out string lengths in C/C++ even... but, then again? C/C++ probably HAVE a sizeof too!
Anyways - the trick? Should work! You're probably going to know that already, but it's pretty neat...
Oh - I also noted you put out strings in 16-bit type - std. String type!
(Hence, I think why you cited BORLAND PASCAL (I called it Turbo Pascal, but iirc, there was a "Full-Blown BORLAND PASCAL too, just like there was Turbo C++ & Borland C++ too)
Anyow - There, I noted that Delphi (in 32-bit) used String AND ShortString (couple ways to do it too, that you can still use in practice in Delphi)... & the advantage I am no longer even 'sure of 100%', but it had something to do with heap vs. stack usage, iirc & memory use too! apk
Yup, I noted it in my other reply to you here:
http://developers.slashdot.org/comments.pl?sid=2239636&cid=36455494
In regards to this:
"I think Borland/Turbo Pascal had only strings that were shortstrings (and some versions of Borland Pascal supported also C style strings relatively well). I always wished that they would support longer strings and it is nice to hear that they increased maximum length of Pascal style strings in Delphi." - by gay358 (770596) on Wednesday June 15, @05:17PM (#36455420)
Right! You were talking 16-bit is why in BORLAND PASCAL/Turbo Pascal - I was talking Borland Delphi 2.0 onwards, which was 32-bit...
Hence, my noting the diff. between shortstrings &/or std. string types there.
Memory use & I am FAIRLY sure heap vs. stack allocation were the advantages though as I stated.
---
"Nowadays I use mostly just Java, C(++) and Perl" - by gay358 (770596) on Wednesday June 15, @05:17PM (#36455420)
Ha, & good for you: You're "cross-platform" that way... I recently got into Python for the SAME reasons (& I do Java here as well)!
Cross platform coding being my reasons really!
Delphi had Kylix going & killed it, which sux... it did code in static single .exe form too for BOTH platforms (you didn't need runtimes, which = speed really). There, You could VERY NEARLY "write once, run anywhere" IF you avoided diff.'s in say, sockets work, or filesystems (driveletters in Windows. vs. mounted devices on NIX) etc.
I took a peek @ REALBASIC too, because it does true single .exe files on Macs, Linux, AND Windows (just noting it in case you hadn't heard of it & are interested in such things & capabilities in languages - I am, because you can ALMOST "write once, run anywhere" that way).
---
"but sometimes I feel that I should try using Pascal again as I really liked it. I recently noticed that there is cross platform IDE/library called Lazarus which is some kind Delphi clone." - by gay358 (770596) on Wednesday June 15, @05:17PM (#36455420)
There is, & that one, I've tried... it is nearly EXACTLY like Delphi is in the IDE, in fact, unbelievably so!
However - I couldn't "get it going" with the 64-bit version of FREE PASCAL (which is what Lazarus used) & I am not sure if the dev. still works on it anymore or not!
HEY - I'd LOVE to have Delphi in 64-bit here, & NOT the .NET runtime driven stuff only (which is what Delphi became after Delphi 7).
I.E.-> I liked building "true stand-alone executables" is why (yes, yes, I know - every app has dependencies on the API libs/dlls, but I like avoiding runtimes IF possible too).
---
"Perhaps I should try it." - by gay358 (770596) on Wednesday June 15, @05:17PM (#36455420)
Perhaps! I think you'll like it, & afaik? Lazarus works "right off", IF you stay 32-bit with it...
Again, I couldn't get it to work right with the 64-bit version of FreePascal but... it's been about a year since I looked @ it last as well (things MAY have changed).
APK
P.S.=> You would have LOVED Delphi, & I think you'll like Lazarus/Free Pascal... & nice talking to you! apk
What I noted does PRETTY MUCH what C/C++ & PASCAL's "sizeof" does (I am pretty sure @ least), albeit with strings:
Take a string, let's use 'mellow'.
If you put 1 pointer thru it, @ 1/2 the size of another (or rather, one pointer thru it and one other one always positionally DOUBLE THE SIZE OF IT)? You can find the length of a string in C/C++ that way (just a 'trick' really).
Understand now?
APK
P.S.=> Think positionally!
E.G.:
First pointer is at location 1 in 'mellow' (m), the second 'double size' one is at 2 (twice it's size, (e)).
First pointer advances to 2 (e), the second 'double size' one is now at 4 (l)...
And so on, until you "errout/abend" (which the doublesized 2nd pointer WILL do, which is why I noted errtraps like Try-Catch/Try finally (etc., same idea, JAVA, Pascal, Python & other languages have that errtrap construct)).
In the end, in the errtrap? 1st pointer - 1/2 sized one SHOULD BE MIDPOINT & doubling it is length of string (character array really)!
That, or use the last result of the 2nd doublesized pointer prior to abend, & bingo - size of string! apk
32 bit full support, that I know, for a fact, AND the "way I like apps", as "stand-alone single .exe files" ala:
---
APK Registry Cleaning Engine 2002++ SR-7:
http://www.techpowerup.com/downloads/389/foowhatevermakesgooglehappy.html
---
Amongst around another 30-40 apps I put out as shareware/freeware over time (did a LOT of that as a student in the early to late 1990's & "finalized them all" by 2001).
I loved it, hence, why I WISH there was a 64-bit Delphi that didn't use a runtime for .NET!
---
You're probably RIGHT about using DPMI too, but that's sort of "hokey" don't you think? Small bucket into higher memory out of conventional memory iirc... right??
APK
P.S.=> I'd love to port a lot of the wares I put out online into 64-bit models is why - without having to change the language (porting PASCAL to C/C++ or VB is cake though I think (well, not really "cake" but, doable))... apk
I could have stated this using zero-based arrays as I should have:
"First pointer is at location 1 in 'mellow' (m), the second 'double size' one is at 2 (twice it's size, (e))." - by Anonymous Coward on Wednesday June 15, @05:47PM (#36455760)
By "at location 1" could have been said location zero instead (because they use zero based array positioning for 1st slot etc.).
APK
P.S.=> I think you get my point anyhow though... lol! apk
Has anyone here actually tried to duplicate the tests? Surprisingly, it seems not.
As checked in, it won't even compile for the Java version. There is a stray 'b' character in one of the files. Who has such bad processes that they can check in something that does not compile?
Fixing that, it takes under a second to compile the Java version on my laptop. Since they report over 3 seconds, it seems like either my laptop blows away their equipment, or something is wrong. They do claim they ran on an old Pentium 4. Why would anyone do that?? Still, compiling the C version takes 1.7 seconds, twice as long as the Java compile.
Then, running the test produces a stack overflow.
Would anyone accept this kind of sloppiness at work?
Albeit on DYNAMIC strings too, not just static ones like Delphi 16 bit only had!
(In fact? It's useful there, and on arrays work also (since strings are just really "character arrays" anyhow)).
As 16-bit Turbo Pascal &/or BORLAND Pascal 16-bit didn't HAVE dynamic arrays though (Delphi does, but didn't really until Delphi 4 iirc thru Delphi 7 (the ones I like & for reasons already stated)).
APK
P.S.=> Think about this, positionally, using pointers:
StringVar:= 'DELPHI';
I send in a pointer to position #1 (zero). I send another but it's ALWAYS DOUBLE THE SIZE OF THE 1st POINTER.
Thus, pointer 1 is on 'D', & pointer 2 (double size one) is on 'E'.
I vector pointer 1 to position 2 now ('E'), the 2nd pointer is double its size, so it now is at position 4 ('P').
I vector pointer 1 to position 3 now ('L'), the 2nd pointer is double its size, so it is now at position 6 ('i') in 'DELPHI'.
I vector pointer 1 to position 4 now ('P'), the 2nd pointer will cause an abend/err (hence why I noted the 'errtrap' method, to prevent crash & gracefully exit... nice part is? In the err/abend you can send the value of pointer 1 @ midpoint now, to the return value from your function!
This SHOULD work fine on ANY DYNAMICALLY ALLOCATED STRING TOO! Think about it.. gotta run to the store now!
... apk
It's news in a sense that it shows that modern Java JIT compilers still can't optimize as efficiently as modern C++ AOT compilers (note that Java isn't really interpreted, at least not if you run that code a few thousand times to "warm up" before hand - it's all compiled to native code).
Though, really, this perf difference has more to do with the fact that Java memory model is more high-level (in particular, it is verifiably memory safe), and that places much more of a burden on optimizer to implement it efficiently (e.g. escape analysis is needed to allocate objects on stack). In C++, you just give the programmer the ability to deal with memory as he sees fit, which leads to fast code when it's written correctly, and spectacular buffer overflow exploits when it's not.
You jest, but what they've tested here is not a language, but a compiler and a runtime.
As someone who writes compliers, I can tell you that the language is just syntax and form. The only "performance" test you can do on a damned language is to see how fast it is to code something. Here's a basic BASIC example.
PRINT "Retarded Test is Retarded."
C:
puts( "Retarded Test is Retarded." );
Java:
System.out.println( "Retarded Test is Retarded." );
C++
std::cout << "Retarded Test is Retarded." << std::endl;
Out of all of these languages, BASIC has the most "performance" in terms of simplicity, key presses, parsing, number of symbols / tokens, etc. (for this test).
What's to keep all of these languages from to compiling (JIT for interpreted/VM languages) the above source codes down to the EXACT SAME sequence of machine code instructions?? NOTHING!!!!!!! Is BASIC now just as fast as C++ or Assembly Language for that matter?
Point being: Languages have little to do with CPU performance of compiled / executing code -- They didn't even test the damn C++ code in more than one COMPILER, which is where your real optimization happens. Seriously, I wrote a language that's a subset of JavaScript that can optionally compile to machine code, and is faster than the exact same valid JavaScript code running in your web browser. Comparable code in G++ is slower, does this now make the JavaScript language faster than C++ ???
Nothing to see here folks. They didn't test shit. If the two input programs perform the same tasks and produce the same output / results, but are simply described in two different languages, then what's to keep any sufficiently advanced optimizing compiler from generating the EXACT SAME machine code? NOTHING. Languages are how you describe to the complier what you want to do, it's the compiler / interpretor that is responsible for "CPU" performance.
Look at performance critical applications: High profile web sites, User Customizable Modules, Super Computer projects, data base integration, etc. Any time performance is high on the list people pick Java, Lua, Lisp, Pascal, PHP, Perl, Python and sometimes JavaScript. Platform independent (byte-code) deployment is the only feasible choice. The most expensive part of a project is its development time. Using a language that reduces this essential.
One thing that VM byte-code interpreters and just in time (JIT) compilers give is the ability to tune the algorithm based on real execution profiling for multiple hardware platforms, without additional software rewrites. If you compile to machine code at some point you will run into language implementation decisions that the naive coder's control, and you will hit a wall because they could never imagine all future platforms.
The computing field changes at an accelerating rate, now with ARM, x64, and even newer x86 chips, or even newer compilers on the same hardware, newly compiled code runs faster than the old binary you build 5 years ago. It is folly to produce software that is not portable to future hardware. This means more work on the part of the platform implementers, but the gain is significant because every program benefits when you upgrade the platform without having to spend development money on a per project basis. Centralized improvements give better distributed results.
If other things like program execution speed are important (they rarely are, most frequent bottlenecks are IO latency -- even in video decoding) then use a native language interface to a compiled language like C (+ Assembly), which nearly all VM languages have support for. This allows you to take advantage of the ease of modification and make the best of programmer time, without sacrificing the ability to fine tune a small processor intensive section (for each targeted environment). Compiled languages may be faster once, but one size does not fit all -- And one set of machine code instructions is rarely fastest for all platforms, even when it's the same platform (x86 compiled for a Generic is slower than AMD or Intel specific targeted code).
RTTI and exceptions
I can see how these are useful on PC- or smartphone-class hardware, but the support library adds substantial space overhead on embedded systems with 288 KiB of RAM and a 16.8 MHz CPU.
in fact, C++ adds compile time code reduction through the template facility
Templates are easy to inadvertently abuse once templated methods get instantiated once for each of several types. For example, sorting an array of each of several types may result in the sort routine getting copied for each type, compared to qsort() which uses the size of an element. What are the best practices to keep template bloat from happening?
I guess a sufficiently determined programmer can hand compile Boost:Spirit to C code
And in fact, this is how early C++ compilers worked, by outputting C code.
What I don't get is why Google is looking at all of these near-iron languages that have gotten so long in the tooth when newer, higher level interpreted web languages are achieving speeds similar to deeper level languages. Aren't most of their applications focused on the web these days? :P
Admittedly, php, Ruby and the like (especially Ruby) are slow as molasses. But look at the new web interpreted language Lasso for an example of a new language which, through Java-like JIT (Just in time) compilation achieves amazing speed - not just of the final product, but also speed of development. There is more than just raw-iron speed when it comes to development...
How old are these languages, anyway? Does everyone who programs in them have a white beard?