The Go Programming Language on the Raspberry Pi

[ajstarks]

The best way to run Go on the Raspberry Pi is to build from "tip".

$ cd
$ hg clone -u default https://code.google.com/p/go
$ cd ~/go/src
$ ./all.bash

My practice is to get a "weekly" every Friday (or when some significant update occurs)

$ cd ~/go
$ hg pull
$ hg update -v
$ cd src
$ ./all.bash

[Heater]

This perhaps not the thread to ask in but I have been trying out Go and node.js on ARM boards including the Pi and I have found that Go is incredibly slow compared to node.js. A somewhat surprising result.

Basically I have a simple websocket client written in both JS and Go which simply connects to a server and then pumps out little structures in JSON as fast as possible.

JS can do this almost 10 times faster than Go.

Looking at how it runs I see the Go version is stuttering and stalling for every second or so, looks like a garbage collection issue.

Anyone have any thoughts about this? I could post the code somewhere if you like.

[larsth]

This perhaps not the thread to ask in but I have been trying out Go and node.js on ARM boards including the Pi and I have found that Go is incredibly slow compared to node.js. A somewhat surprising result.

Basically I have a simple websocket client written in both JS and Go which simply connects to a server and then pumps out little structures in JSON as fast as possible.

JS can do this almost 10 times faster than Go.

Looking at how it runs I see the Go version is stuttering and stalling for every second or so, looks like a garbage collection issue.

Anyone have any thoughts about this? I could post the code somewhere if you like.

It is likely you are using new (and/or 'make') in the naive way, and this naive way will invite the garbage collector in your Go program to use a lot more memory than needed.
If the program is using the naive way it could be using several times the amount of memory the program really needs to use.

The naive way is not to use memory buffer(s), and not to have a single place in your program where 'new' (and/or 'make') is used. That single place in you program is a go routine that takes care of memory management by using one or more memory buffers. You communicate with the go routine by using a channel, which is thread safe.

Read this Cloudflare article "Recycling Memory Buffers in Go":
http://blog.cloudflare.com/recycling-me ... fers-in-go

If you do profiling of you Go program, i guess you will see something like the first graph on the Cloudflare web page.
Web page about profiling Go programs on the golang website:
http://blog.golang.org/profiling-go-programs
You should always include profiling as part of the tests that are done before a program is used in production.

---

A technique like memory buffers is called free lists, and is used in large programs, because allocating and freeing memory is expensive system calls.
If free lists wasn't used in those programs they would had anything from bad to really bad performance.

[Heater]

larsth,

Thanks for the information there.

Hopefully I will find time to revisit my Go vs JavaScript testing with your suggestions in mind.

What I don't quite get is:

Let's assume both my JS and Go programs are written the most naive way, which is probably true. So they both need to do a lot of memory allocation, deallocation and garbage collecting. How come the Go garbage collector is so much worse?

If I'm having to all that work profiling and changing my code in order to mach the speed of JS I might as well use JS in the first place.

[larsth]

First you question:

Let's assume both my JS and Go programs are written the most naive way, which is probably true. So they both need to do a lot of memory allocation, deallocation and garbage collecting. How come the Go garbage collector is so much worse?

Probably because Go is a very young programming language, where the garbage collector(GC) is more simple than compared to the GC in the JS engine, and thus requires you to think more about how you are using memory.

Doing a lot of allocation and deallocation is obviously the wrong way to use the Go programming language.
In fact that is the wrong way to to use memory like that in any kind of garbage collected language (Javascript included).

You cannot pretend that Go is a scripting language.
You just have to accept that you are running on the metal (=microprocessor), and that the Go program doesn't have a virtual machine between your program and the metal.
That requires you to think more carefully about what you are doing.

If I'm having to all that work profiling and changing my code in order to mach the speed of JS I might as well use JS in the first place.

I guess that you are not used to profile your programs.
It is common to do some profiling on compiled code, to see whether or not you can make some inexpensive (in development time) changes to get a lot of extra performance and/or a lot less memory usage.

The optimized Go program on the golang profiling web page is more than 11x times faster than the original Go program, and it uses ca. 3.7 times less memory than the original Go program.
The optimized Go program is very close to the equivalent C++ program in both speed and memory usage.
You won't get CPU and memory usage that are close to a C++ program with a scripting language .

Profiling isn't much work in my book, but I am also coming from the compiled languages, not the scripting languages.

It is about knowing your programming language - knowing what the compiler is doing under the hood.
If you continue to use the Go programming language you will at some time in the future automatically know which language constructs is the best one to use. By using that knowledge you will in return get lower memory and CPU usage compared to when you was a new user of the programming language.


You may want to let Go become older, and return to it at a later time.

[Heater]

larsth,

It's hard not to do a lot of allocating and deallocating in JavaScript. You don't have enough control to say:

"Here is the memory I want you to keep this object or array in. Oh and by the way next time I create one of these objects or arrays I want you to use that same memory"

Performance gains can be had by using typed arrays for buffers and such like but I have yet too delve into that.

I guess that you are not used to profile your programs.

Oh but I have. Often the idea is to never use memory allocation and garbage collection, in real-time embedded systems for example.

You won't get CPU and memory usage that are close to a C++ program with a scripting language.

Oh but I do. One of the first things I did when I discovered node.js is recreate one of our C++ server processes in JavaScript. This thing sucks in streams of XML messages, thousands per second, it filters and routes them out
to other client processes that subscribe to various kinds of data.
The JS version has about the same memory foot print and runs at about the same CPU loading. I was stunned at the results.

I was looking at Go to perform that kind of work but my results were very disappointing.

Of course JS will normally be a lot slower than compiled code. But the trick here is that most of the actual work is being done by native code in the libraries you are using. In the case above that is libexpat and the underlying
networking infrastructure.

Actually that is becoming less true. With emscripten you can compile/translate C++ code to JavaScript and it will run within an order of magnitude of the native speed!

I will certainly be looking at Go in the future. I'm going to try and find time to try and optimize my simple networking example.

[calistra]

Having been through the pain of installing on Raspbian, I was happy to type

Pacman -S go

Under Arch and get the latest version

[m.e]

These installation instructions appear to be out of date.

[ajstarks]

yes, this is an old thread. The way I install Go on the Raspberry Pi to is install from source:

1) get the source from https://golang.org/dl (the latest as of this writing is go1.4.2.src.tar.gz)
2) untar (I untar it into $HOME/go)
3) cd $HOME/go/src
4) ./all.bash

Note that building from source on the Pi will take while

Alternatively, you can use Dave Cheney's tarballs:

http://dave.cheney.net/unofficial-arm-tarballs

[ajstarks]

Note that as of Go 1.5 (currently under development, build process will change, because the toolchain will be converted from C to Go, and you will need a 1.4 version to bootstrap.

See: https://docs.google.com/document/d/1Oaa ... FGV28/edit

[jpmathew]

I compiled go1.4.2 on the Pi, and then compiled go1.5 using the 1.4.2 as a go compiler.
This worked OK, except for a couple of tests. But when I check go version it shows go version devel +2468227 instead of 1.5.
Used go 1.5 and compiled some code and it seems to work. Need to check goroutines. Got gosigar working OK.
Is the go version an error?
Thanks
Joseph Mathew

[larsth]

I compiled go1.4.2 on the Pi, and then compiled go1.5 using the 1.4.2 as a go compiler.
This worked OK, except for a couple of tests. But when I check go version it shows go version devel +2468227 instead of 1.5.
Used go 1.5 and compiled some code and it seems to work. Need to check goroutines. Got gosigar working OK.
Is the go version an error?
Thanks
Joseph Mathew

On my netbook (i386 arch, Linux OS) i get:

Code: Select all

go version go1.5 linux/386

Instead of doing the Fetch (https://golang.org/doc/install/source#fetch) step, I would just download go1.5-src.tar.gz from https://golang.org/dl/, and create a Go 1.5 from that src code.

I am currently creating a Go (1.5) program for the Raspberry Pi, and I just sets GOARCH to something else. After a successful cross-compiling I scp the program to the Raspberry Pi.
In LiteIDE is easy to set GOARCH to "cross-arm5", or "cross-arm6", but currently it is set to "linux32-local".