Go Getter Part 2

Oct 3, 2013 · 2 minute read · Comments
programming

*Update: I have now posted a second follow up article with the benchmarks rerun with a multi-threaded optimized C++ version

Apples? Oranges?

This is a follow up article to the initial Go Getter article which focused purely on optimizing the Go solution. The comparision was not apples-to-apples (and still isn’t; as we are talking about two very different platforms here) and was never meant to be. Instead it was focused on:

• Learn idiomatic Go
• Document optimizations which help make the Go solution faster
• Fire up all cylinders (erm cores) and see how the performance scales
• Discover any avenues of optimizing Go further (after all, we are just at version 1.2rc1)
• Fun?

It was never meant to mislead people into believing that Go was faster than a fully optimized C++ solution, or to deceive people into adopting Go as a result. Since its been a while (7 years) I went knee deep into C++, I had left it upto more experienced hands to properly optimize the C++ version. Evidently, it was wishful thinking.

Full Steam Ahead

I spent the last couple of hours applying the optimizations learnt from the Go story to the C++ version: diff of the optimizations

Needless to say, the C++ performance is exciting again. Mind you, although I tried using OpenMP to bring in some multi-threaded love, it didn’t work out so well. So I will truly have to leave that upto more capable hands.

It was compiled by “c++ -O3” using G++ 4.7.3 and benchmarked on a Core i7 2600 16 GB dedicated Hetzner server running an updated Ubuntu 13.04 installation

Road Ahead

I hope to takes these numbers to the Go community and try and close the gap as much as possible. Go suffers from relatively slower performance because it tries to be as safe as possible when used in a concurrent scenario (for example, the default “global rand” is synchronized and good to access from multiple goroutines.) That is something I would definitely desire when doing real world coding. There is definitely scope for improvement, but considering everything else (GC, compilation speed, goroutines, channels, etc.) that Go brings to the table, I guess it will always be a game of balance.

As usual, reachable at kidoman@gmail.com / karanm@thoughtworks.com / @kid0m4n

Reddit Discussion Thread
Hacker News Discussion Thread
Tweet this