Go Performance

Posted on by

I’ve been learning Go over the past couple of weeks to get a broader view of languages, programming styles and idioms in general. Working purely in C++ can give you a slightly blinkered view. When you look at other languages you need to initially accept their way of doing things before you question it.

Hacker News, in particular, seems to mention Go a few times a week, and there is generally something interesting in each post.

One thing that comes up is Go performance, and interestingly, there is this post on Krzysztof Kowalczyk’s website.

The post refers to the alioth benchmark shootout web site with a comparison of Go to Java 7, finding that Java 7 is generally faster than Go in the benchmarks. What Krysztof’s post also describes is the uneven implementation of the benchmarks: the Java version (and presumably the C and C++ versions) are closer to the optimal implementation for those languages than the Go version is.

In short this benchmark site, whilst good for a quick look up of performance for mature languages with large developer communities, isn’t particularly good for new languages with smaller development communities. As with anything on the web these days, take it with a pinch of salt.

What is Go good for? As long as you don’t want a GUI (though you can use Qt bindings), any console or server side process can usefully be written in Go. Through correct use of go-routines, your process will scale with the number of CPUs/cores (concurrency is not parallelism). Not many other popular languages offer this out of the box, and certainly not with such ease and readability.

The general feeling I have from the last few weeks of searching, reading and watching Go articles and videos, is that Python and Ruby may (YMMV) be usefully retired in favour of Go, and for pure development speed with reduced development bugs, many C and C++ tasks may also be usefully replaced with Go (except where raw performance is a consideration). Go is a young language and performance is only going to get better.

Common wisdom in computer science is ‘use the best tool available’, and in terms of programming languages: ‘use a domain specific language’, yet many, many, developers still cling to one language to solve all problems when others are much more applicable. Even though Go doesn’t really have classic OO, or generics, I think Go is going to become an increasingly popular and useful language as it is currently one of the best tools available for getting improved performance on improving hardware without having to rewrite the code.

I just have to find a useful project to Go on: for the man with a hammer, everything looks like a nail!!

  • Isaac Gouy

    >>the Java version (and presumably the C and C++ versions) are closer to the optimal implementation for those languages than the Go version is<<

    and that's because…?

    Ummm because those Go programs were written by "The Go Authors"? ;-)

    • Barry Lapthorn

      As KK says on his website, the reverse complement benchmark does unnecessary copies, which one thing that the Java program doesn’t do. Looking at the code itself, here, http://shootout.alioth.debian.org/u32/program.php?test=revcomp&lang=go&id=2, it’s submitted by ‘kp anonymous’, so as far as I can tell that’s not one of the Go authors (such as Rob Pike, for example). It certainly seems to me at least that there is an unevenness in the quality and equality of benchmarks on that site, which is unfortunately a problem of benchmarks like this in general.

      • Isaac Gouy

        I’ve re-run The Go Authors revcomp program (see Go #3), just for you, so that you can see it’s a tiny bit slower than the ‘kp anonymous’ program. (The slower programs eventually get removed.)

        >>benchmarks like this in general<<

        Do you mean "in general" or do you mean "hypothetically"? (Which other actual benchmarks are you referring to?)

        • http://www.lapthorn.net Barry

          I see what you mean now I’ve found the URL: http://shootout.alioth.debian.org/u32q/program.php?test=revcomp&lang=go&id=3, which is a different version of the code to that which is referred to in the article above.

          By ‘in general’ I mean several things: any meaningful benchmark is of sufficient complexity that it can be coded in different ways; compilers, and compiler flags aren’t necessarily equivalent between languages; developer familiarity with a language is also not sufficiently equivalent. So newer languages tend to suffer in benchmark tests like this as their compilers are improved and their developers learn how to using language specific idioms.

          Indications are the that the next releases of Go are going to improve performance significantly in many cases (see link in original article).

  • Isaac Gouy

    Incidentally, Krzysztof Kowalczyk’s program is a little faster than the previous Go program on x86 but is slower on x64.

    http://shootout.alioth.debian.org/u64q/performance.php?test=revcomp

    • Isaac Gouy

      My mistake — Krzysztof Kowalczyk’s program was *slower* than the previous Go programs on every benchmarks game configuration — both one-core x86 x64 and both quad-core x86 x64.

      Krzysztof Kowalczyk mistakenly made his time measurements against the tiny tiny 10KB input file that’s provided just so contributors can check their programs kind-of work before they contribute them.

      The final benchmarks game reverse-complement repeated-measurements are made with a 250MB input file.

  • http://www.lapthorn.net Barry

    >> What’s the evidence for performance improvement?

    as per the link in my article: https://groups.google.com/forum/#!msg/golang-nuts/RxQ96lckPQ4/FGoCau6OFoYJ

    >> Benchmarks tests show newer language implementations as they are — not as advocates hope they will be at some time in the future.

    >> Also, the implementations of older languages are often updated, and their developers have to learn how to use the new idioms.

    I don’t disagree, and in fact stated as much above.