How fast can Go go?

Question

Go is one of the few languages that are supposed to run 'close to the metal', i. e. it's compiled, statically typed and executes code natively, without a VM. This should give it a speed advantage over Java, C# and the like. It seems, however, that it's behind Java (see the Programming Language Shootout)

I'm assuming that less mature compilers are hugely responsible for this, but are there any other reasons? Is there anything inherent in Go's design that would prevent it from running faster than, say, Java? I have a very unsophisticated view of runtime models, but it seems that at least in principle it should be able to run faster than Java, thanks to native code execution.

Answer 1

In terms of language design, there isn't really anything that should make Go slower than Java in general. In fact, it gives you more control of the memory layout of your data structures, so for a lot of common tasks it should be somewhat faster. However, the current primary Go compiler, scheduler, garbage collector, regexp library, and a lot of other things aren't particularly optimized. This is steadily improving, but the focus seems to be on being useful, simple, and fast enough over winning in microbenchmarks.

In the linked benchmark, Go loses big to Java on the binary tree and the regexp test. Those are tests of the memory management system and regexp library respectively. Go's memory management could be faster and will certainly improve over time, and the current standard regexp library is a placeholder for a much better implementation that is soon to come. So, losing on those two isn't surprising, and in the near future the margin should be more narrow.

For the k-nucleotide benchmark, it's somewhat hard to compare because the Java code looks to be using a different algorithm. The Go code will certainly benefit from compiler, scheduler, and allocator improvements to come, even as written, but someone would have to rewrite the Go code to do something more clever if we wanted to compare more accurately.

Java wins in the mandelbrot benchmark because it's all floating point arithmetic and loops, and this is a great place for the JVM to generate really good machine code and hoist things at runtime. Go, in comparison, has a pretty simple compiler that doesn't hoist, unroll, or generate really tight machine code currently, so it's not surprising it loses. However, one should keep in mind that the Java timing doesn't count the JVM start-up time or the many times it needs to be run for the JVM to JIT it nicely. For long-running programs, this isn't relevant, but it matters in some cases.

As for the rest of the benchmarks, Java and Go are basically neck-in-neck, with Go taking significantly less memory and in most cases less code. So, while Go is slower than Java in a number of those tests, Java is pretty fast, Go does pretty well in comparison, and Go will probably get notably faster in the near future.

I'm looking forward to when gccgo (a Go compiler that uses the gcc codegen) is mature; that should make Go pretty much in line with C for many types of code, which will be interesting.

Answer 2

1. Without even saying which problems were solved, the whole benchmark is pointless.
2. JVM and CLR both use JITs to produce machine code. There's no reason this should be slower. It just costs you ages to boot.
3. Go was designed to build fast. You don't have tons of compile time and boot time optimizations. Go compiles its own standard library by the time a Java app has booted.

Could Go be faster at runtime? Yes. Will Go ever be faster at runtime? I don't know. Maybe the compiler builders will add optional optimization at the cost of compile time. But I don't think they have much interest in that. They work at Google.
What they want is a language that allows fast development and that performs good at what they do. Hell, even if that benchmark was credible, it would mean they are half as fast as C and 14 times as fast as Python. This is more than good enough.
Hardware is cheap, code is expensive. Code tends to become bigger and slower as you invest money, hardware becomes cheaper and smaller. You want a language, that doesn't require 4 frameworks and 2000 classes to accomplish anything useful.
There's nothing inherent in Go's design, that makes it slow. However there's something inherent in Go's designers, that makes it slower than assembly: common sense.

Answer 3

I've also noticed that Go was particularly slow in the regex-dna benchmark. Russ Cox explained why Go wasn't that performant in this particular benchmark. The reason is that Go's regexp package is using a different matching algorithm that performs bad in this particular benchmark but might be by a magnitudes faster in other benchmarks. Also Ruby, Python and other scripting languages are using a C implementation of another regexp matching algorithm.

Finally the Computer Language Benchmarks Game consists of micro-benchmarks that might not accurately reflect many characteristics of the measured languages and even mediate wrong impressions. This research paper, recently published by Google gives a more accurate overview of several language characteristics of Go, Scala, Java and C++ — particularly the "V. Performance Analysis" part. So in the end Go's almost as memory-hungry as Java (81% of Java's memory) and consumes even 170% as much memory as Scala (couldn't find in the paper whether JVM's memory consumption was considered).

But again, Go's young and still under heavy development (API changes)! Many improvements are coming soon.

Answer 4

Go is faster than Python and a little slower than Java. My rough experience has found Go to be much (1-2 orders of magnitude) faster than Python, and about 10-20% slower than Java. However, Go is slightly faster than Java if it used with quad-core (x64). Go also is a lot more efficient in the terms of memory RAM.

I'd like to add some points about Go's potential for performance vs Java and Python. Go allows more of the things that C does which constantly allows C to outperform most other languages. Cache misses are quite important to avoid for high performance code. Reducing cache misses requires controlling the memory layout of your data structures. Go allows you to do that. Java doesn't which makes it harder to avoid fracturing of memory and cache.

Right now Java usually runs faster than Go, because Java garbage collector is a lot more sophisticated. Although there is not reason the Go garbage collector couldn't be a lot better. Code generation is also likely a lot better for Java at the moment. Go has a lot of potential to improve e.g. with support for vector instructions etc.

So I think it is really just a question of time before Go edges past Java. Although like with any language code isn't likely going to be faster automatically by being written in Go. You have to utilize the facilities the language gives you. I'd say Go simply gives more opportunities to tune your code.

Anyway, that's just one developer's experience.