First experiments with golang

I finally found some time to look at the Go programming language (aka golang). In order to get a feeling for it I picked a random Google code jam problem and programmed it in Go.

The code used in the experiments that follow is pretty simple

first impressions

My first impressions were mostly positive: Go has

  • decent documentation covering the language proper as well as the standard library
  • a fast compiler resulting in short edit-compile-test cycles
  • a nice standard library and a wealth of packages (provided by the community)
  • a lively and friendly mailing list and irc channel

The language has quite a “direct” feel to it: I could get to work and be productive almost immediately.
This is in stark contrast to other languages I tried to learn recently e.g. Scala (back in January): it required a lot of reading and even a couple of days into it I was not really productive in Scala.

Go is quite the opposite, the barrier to entry is low, the language is clean and simple. The combined declaration and initialisation operator (':=') alone is a godsend.

Coming from a Python background the main thing I was missing was the REPL. Who knows, maybe there is even one out there but I just did not find it yet..?

playing with goroutines

One of the most attractive golang features is its support for concurrent programming via goroutines and I wanted to play with these.

The programming problem chosen came with an input for 50 calculations. I used it to create inputs with 50, 100 and 200 *thousand* calculations. All calculations are independent of each other i.e. ideally parallelisable.

Being a fairly young language still Go does not parallelise code by default. If CPU parallelism is desired one must tell the run-time how many goroutines shall execute simultaneously.

The code I wrote starts each calculation in a separate goroutine and allows the user to specify the number of CPUs/cores that should be used to execute the program.

Using a bash script I ran the resulting program varying both the number of calculations and the number of CPU cores.

These experiments were conducted on a 32-core server (Quad-Core AMD Opteron Processor 8356) with 64GB of RAM running Ubuntu 11.04 server. Also, I ran each configuration for three consecutive times and used the average duration in the graph below.

Apparently the golang run-time was not able to utilise more than 8 cores when running this particular program.

50, 100 and 200 thousand calculations running on 1 through 16 CPU cores

As can be seen from the graph (full size) above, executing the program on more than 8 cores did not decrease its running time futher.

The 200K calculations input file is a bit over half a gigabyte so I suspected that the program is dominated by I/O and the goroutines cannote execute because the result channel is full.

That lead me to experiment with different result channel sizes. The resulting running times (e.g. for 200K calculations) can be seen in the graph (full size) below.

The 200K calculations running on 1 through 16 CPU cores and with varying result channel sizes

However, varying the result channel sizes did not seem to have a big effect.

Anyway, I am pretty happy with the code at this point but suggestions are always welcome, particularly those aiming at improving the degree of parallelism 🙂


I am amazed how far I got by investing approx. 10 hours in learning Go and programming in it.

Having used python almost exclusively for the last 5 years I am pretty spoiled when it comes to code conciseness and productivity.
Go is not too far away though, and, programming in it was fun and enjoyable.

I will definitely continue to explore it. Maybe you should give it a whirl as well 🙂


3 thoughts on “First experiments with golang

  1. Hi Muharem,

    Here’s a tip from Gustavo:

    Btw, as a useful hint if you’re just starting with Go, I recommend
    using hsandbox for experimenting with it:

    bzr branch lp:hsandbox

    This is a single Python file which implements a very tight
    experimentation loop for several languages (Python, Go, C, C++, Shell,
    etc), so you get a divided screen and every time you save the file at
    the top of the terminal it’s immediately compiled (if necessary) and
    executed on the bottom one.

    This replaces very nicely the lack of a good interactive interpreter
    on some of these languages, which we’re used to in Python.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s