

Playing with Go1.1beta2, it's much faster - voidlogic
http://blog.ant0ine.com/typepad/2013/04/go1-1-beta2-much-faster-.html

======
afhof
One wonders what Go was doing with that extra 36% time in the previous
version. Was it all due to map memory allocation and associated cache misses?

~~~
coldtea
Well, 36% is not a large improvement at all, considering Go is still slower
than Java.

Go has a some way to go still and it can be improved in all areas: GC,
algorithms, heuristics, code generation, ...

~~~
cmccabe
Slower than Java at what?

At program startup time? Java is a joke in this area.

At memory consumption? Java has a high fixed memory cost. It also uses more
memory than Go does. There are fundamental reasons for this. Java needs to
keep around runtime type information because the code can change at runtime
due to new classes being loaded. Go does not. Java also chose to implement a
scheme where any object can serve as a mutex or condition variable. The result
is a few words of extra memory per object when compared with Go... usually
somewhere in the neighborhood of 8 or 16 bytes per object, depending on
architecture. Using memory efficiently is _HUGE_ in modern architectures and
Go is better at that.

Go also gives you more control over how your program uses memory. This is
because Go has both pointers and value types. The result is that things that
would have had to be "boxed" (i.e. separate memory allocations) in Java can be
unboxed in Go. If you know C, think of it as the difference between doing a
malloc for each structure element, and just having a bunch of structs stored
by value inside another struct.

Go is faster at interfacing with native code. Have you checked the speed of
JNI lately? Speaking as someone who's written a lot of JNI... it's not pretty.

Java still has the edge in one area: HotSpot has a precise garbage collector,
something Go doesn't currently have. But I have a feeling that gap is going to
be closed.

Note: I am oversimplifying the unboxing discussion a bit. In theory, it might
be possible to unbox certain structures in Java, such as non-nullable final
fields. However, Go preserves a lot more of the intentions of the programmer
in this regard-- and without knowing how the programmer intended to use the
memory, most optimizers will struggle.

~~~
trailfox
For most applications the startup time is irrelevant. The startup time of a
server app which runs for months is not an interesting data point. The
throughput in requests per second is far more important and this is where the
JVM has been very strong (3x faster than Go 1):

[http://www.techempower.com/blog/2013/03/28/framework-
benchma...](http://www.techempower.com/blog/2013/03/28/framework-benchmarks/)

Memory consumption is often not a major concern on modern systems, saving 50
MB or even 500 MB is seldom as important as the ability to process more
requests per second.

I'm busy learning Go, and am very impressed by the performance gains in 1.1
(and GC improvements). My main concern at the moment is how much less
expressive the language is relative to Python, Scala and Ruby. Go is fast, but
so is Scala, and Scala is also very expressive compared to Go.

Go has a definite edge in environments where memory footprint is important and
simple interfacing with native libraries is critital. Scala and the JVM are
still more appealing to me in most other areas.

~~~
agentS
To be fair, I would rather write this:
[https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...](https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/go/hello.go)

rather than this:
[https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...](https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/netty/src/main/java/hello/HelloServerHandler.java)

(not to mention the 2 other Java files to setup the server).

~~~
icebraining
Well, that's using a particular framework (netty). Play seems much simpler.

~~~
coldtea
Not to mention this gives you a lot of flexibility and quite a battle tested
backend, whereas the Go equivalents are still mostly in progress and less
flexible.

Oh, and in the recent shootout, netty gets to 30,000 rpm, whereas Go peaks
around 10,000.

~~~
voidlogic
First off, is was 14k vs 38k. Just wait until next benchmark update when they
have switched to Go 1.1

Based on these results Go and Netty should be much closer:
<https://gist.github.com/errnoh/5320784>

------
jgrahamc
It's a pity this is a comparison with Go 1.0.3. That's so old as to be a
almost useless comparison given that everyone who's serious about Go uses
something from the hg repository.

~~~
trailfox
Those serious about Go are running (production?) systems using pre-release
builds? Is that a common practice?

~~~
enneff
It's not very common. John (the GP) uses the Go bleeding edge at CloudFlare
because he needs some of the recent improvements. To do this, he really needs
to know what he's doing (and he does). Typical Go users just use the stable
branch.

~~~
voidlogic
I know of two more Go heavy start-ups and one large company that also use tip.

