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." ®