Things that make Go fast

Escape analysis, dead code elimination, and function inlining are standard optimizations taught in an undergraduate compilers course. Go is cool, but I wouldn't really cite those as justifications for why.

Unfortunately, Go&#x27;s compiler is not as fast as it could be; most of the optimizations presented here were already made by compilers in the 80s.<p>The fact that modern compilers are a really complex piece of software that took dozens of years to write and improve to the state we are at doesn&#x27;t helps. Hopefully, switching to a compiler written in pure Go in Go1.4 (IIRC) will allow code maintainers to benefit of Go&#x27;s simplicity.

The comparison between GO and Java seems unfair, given they compare a primitive variable with an object... which has methods and a bunch of other things to increase it&#x27;s size (for good reason).<p>Sure GO may be quick... but a JIT&#x27;ed java program will run at native C speed... because it&#x27;s been compiled down to native code at that point... (and most language performance comparison&#x27;s I&#x27;ve seen pop up generally ignore this fact and measure &quot;performance&quot; by timing runtime which includes the JVM firing up and executing cold&#x2F;non-jit&#x27;ed code... not real-world scenarios for high performance code.)

Function calls aren&#x27;t that slow in an OoO processor - they&#x27;re perfectly predictable branches, so it can just start decoding from over there. There might be a cache miss, but there might also be fewer cache misses, or even better the CPU might skip decoding with a µop cache.<p>Really, the purpose of inlining is so inline functions can be specialized for their new context, which can easily make the total code size smaller. On x86, size&#x2F;speed tradeoffs just don&#x27;t happen like they used to.

Things that make Go fast*<p>*compared to non-native languages like Python and Java.<p>Could people please stop calling their favourite language fast just because it beats an interpreted&#x2F;VM language.

I was surprised to see stack-check preambles mentioned here. Does that really happen on every function call? Or does it happen on a context switch? Usually stack-checking on function entry is considered something that makes code slow.

Hey, as long as we&#x27;re talking about Go performance - can we please, please get some kind of wide vector intrinsics (ie, no cgo overhead) in a library, or at least aggressive compiler generation of vector ops that actually use AVX &amp; the ARM NEON equivalent?<p>Right now peak floating-point performance isn&#x27;t even within half of what it should be on a very recent CPU, and I&#x27;d love to be able to deploy Go that exposes machine learning models to a network interface.

Go should replace Java in Android Development

Nitpick: goroutine context switch can also happen at function calls (when the stack is being enlarged).