Google pits C++ against Java, Scala, and Go
C++ wins. If you're a genius
Google has released a research paper closely comparing the performance of C++, Java, Scala, and its own Go programming language.
According to Google's tests (PDF), C++ offers the fastest runtime of the four languages. But, the paper says, it also requires more extensive "tuning efforts, many of which were done at a level of sophistication that would not be available to the average programmer."
Go is designed to remove at least some of this limitation, but it's still young (it debuted about a year and a half years ago as an "experimental" language), and on most of Google's performance tests, it trailed C++ as well as Java and Scala. "Go offers interesting language features, which also allow for a concise and standardized notation," reads the paper, penned by Googler Robert Hundt. "[But] the compilers for this language are still immature, which reﬂects in both performance and binary sizes."
That said, Go's compile time was faster than that of all three of its rivals. Java and Scala compile to Java Byte Code, while C++ and Go compile to machine code. Google's benchmark did not test concurrency, an area of particular focus for both Scala and Go. Go was designed to be a concurrent language that offers the speed of C++ but the "feel" of a dynamic language like Python.
Scala – a cross between object oriented and functional programming that runs atop at the Java Virtual machine – edged Java on runtime, and it had a smaller code size and a smaller memory footprint. But it still shares some of Java's limitations. "Scala['s] concise notation and powerful language features allowed for the best optimization of code complexity," the paper reads. "The Java version was probably the simplest to implement, but the hardest to analyze for performance. Speciﬁcally the effects around garbage collection were complicated and very hard to tune. Since Scala runs on the JVM, it has the same issues."
Speaking with The Register on Friday afternoon at a Silicon Valley conference where the paper was unveiled, Scala creator Martin Odersky gave his stamp of approval to Google's benchmarks, which operated on two different levels.
First, Google encoded a benchmark for each language that uses the language's idiomatic container classes, looping constructs, and memory/object allocation schemes – without using language-specific tools designed to maximize performance. "This approach allows an almost fair comparison of language features, code complexity, compilers and compile time, binary sizes, run-times, and memory footprint," the paper says.
Then after the results of the tests were published within Google, various Google engineers optimized the benchmark for each language, and the tests were run again. "While this effort is an anecdotal comparison only, the benchmark, and the subsequent tuning efforts, are indicative of typical performance pain points in the respective languages," says Hundt.
Odersky agrees, at least when it comes to Scala. After the optimizations – which involved taking advantage of Scala's functional aspects – the size of Scala's code and its runtime were significantly reduced. "I particularly like this idea to build a single algorithm from a non-expert point of view, compare the data, and ... then challenge people to optimize," Odersky says. "In a sense, it's fair."
The optimization stage also showed that whereas C++ offers the fastest runtime, optimizing the code is relatively difficult. During the optimization stage, developers also significantly decreased the size of the C+ binary.
According to a post from Googler Ian Lance Taylor on the Go mailing list, very little work was put into the Go optimization prior to the release of the paper, and now, after further optimization, the code is much faster. "Despite the name, the [ostensibly optimized version of the Go] code was never intended to be an example of idiomatic or efficient Go. Robert [Hundt] asked me to take a look at his code and I hacked on it for an hour to make a little bit nicer. If I had realized that he was going to publish it externally, I would have put a lot more time into making it nicer," Taylor says.
But Scala, says Odersky, performed about like he expected. "I know that we are head-to-head with Java. It was a pleasant surprise that we outperformed Java on both the optimized and non-optimized tests, but I don't expect that to be the rule for applications." ®
Caution - old git moan
Once upon a time C/C++ where the primary language of choice for software development. A C/C++ programmer was an 'average' software developer because that's almost the only langauge that was used. Now Google are saying that they're effectively superior to 'average programmer'!
Sorry about the gap, was just enjoying a short spell of smugness.
@sT0rNG b4R3 duRiD. Concurrency in C is just fine, it's no better or worse than any other language that lets you have threads accessing global or shared memory.
I don't know about yourself, but I prefer to use pipes to move data between threads. That eliminates the hard part - concurrent memory access. It involves underlying memcpy()s (for that's what a pipe is in effect doing), which runs contrary to received wisdom on how to achieve high performance.
But if you consider the underlying architecture of modern processors, and the underlying activities of languages that endeavour to make it easier to have concurency, pipes don't really rob that much performance. Indeed by actually copying the data you can eliminate a lot of QPI / Hypertransport traffic especially if your NUMA PC (for that's what they are these days) is not running with interleaved memory.
It scales well too. All your threads become loops with a select() (or whatever the windows equivalent is) at the top followed by sections of code that do different jobs depending what's turned up in the input pipes. However, when your app gets too big for the machine, it's easy to turn pipes into sockets, threads in to processes, and run them on separate machines. Congratulations, you now have a distributed app! And you've not really changed any of the fundamentals of your source code. I normally end up writing a library that abstracts both pipes and sockets in to 'channels'.
Libraries like OpenMPI do a pretty good job of wrapping that sort of thing up in to a quite sophisticated API that allows you to write quite impressive distributed apps. It's what the supercomputer people use, and they know all about that sort of problem with their 10,000+ CPU machines. It's pretty heavy weight.
If you're really interested, take a look at
and discover just how old some of these ideas are and realise that there's nothing fundamentally new about languages like node.js, SCALA, etc. The proponents of these languages who like to proclaim their inventions haven't really done their research properly. CSP was in effect the founding rationale behind the Transputer and Occam. And none of these langauges do the really hard part for you anyway; working out how a task can be broken down in to separate threads in the first place. That does need the mind of a superior being.
pascal is not the answer
If C/C++ is uber now.. my assembler skills must be godlike! (smug mode on).
To the poster above.. pascal is a complete nonstarter. It's like programming java with one hand tied behind your back.
Object pascal? Maybe the poster only used it in a school environment? I help maintain a 1.5 million line project. Suffice to say, its single pass nature cripples it fatally. (I had a whole rant here but deleted it..).
Most of the 'good' ideas from delphi ended up in c# - you'd be surprised how similar they are (right down to identical function names).
90% of the time the language you used is determined by the task. I write Android in Java, iOS in ObjC, my main job in Delphi, maintain others code in C or C++.. One isn't 'better' than another.. Every language has its 'WTF?' moments. What matters is you get the job done, and you don't write an unmaintainable behemoth that will drive the guy you comes after you quetly insane.
Ah the old WTWSDNMS bottleneck
Wishing Things Were Simpler Does Not Make It So.
No computer language can make the problem you are trying to solve any less complicated. A language that makes certain aspects of problem solving 'easier' will just mean you spend more time hoping the problem you are trying to solve consists only of those things your language has 'simplified'.
Think of it a bit like weightlifting - lifting 5kgs is easy but if you have to lift 1000kg then you are going to have to make 200 lifts. If you practice a bit so you can lift 100kg in a go then it only takes 10 lifts. 'Modern' languages encourage you to leave the weights alone and go and stand on the sides of the running machine watching a video instead.