> Go 1.2 produces a binary that performs on the order of 10%-15% faster than the numbers above, which might mean equivalent performance to the Erlang implementation.
Huh, impressive for Erlang, beating a newer, statically compiled language, while being interpreted and with dynamic types.
Erlang's VM is very sophisticated and mature, it is at least years ahead of Go, imo. For example, compare Erlang's pre-emptive scheduling [1] to "goroutines".
Yes, Erlang has admittedly had decades to improve the scheduler (versus a couple of years for the gc compiler in Go), so this is quite literally true.
However, you should know that goroutines are pre-emptively scheduled now; the "scare quotes in your comment seem to imply that they aren't: http://golang.org/doc/go1.2#preemption
I'm a go fanboi, but to be fair, goroutines are now more preemptive, but not completely.
In practice that means that if you call a function somewhere in your infinite loop, you'll get preempted. It's still possible for a single goroutine to steal an os thread.
Practically speaking though, I feel like nobody should be scared away from go due to it's lack of full pre-emption. Seriously, don't write an infinite loop with no function calls.
He's an Erlang novice, but the guy is the best programmer I've met. I have no doubts that if he chose to pick up D instead he'd've written code as fast as mine.
i see no mention of "concurrency" in that article. i see that the go programs make heavy use of goroutines so why were they run in "single threaded" mode? just testing their mqttsrv with various levels of GOMAXPROCS rewards with immediate benefits. here are some numbers for pingtest and loadtest in Go for varying levels of GOMAXPROCS for them and the server:
(pingtest/mqtt gomaxprocs) vs pingtest, reporting "elapsed time":
I mentioned concurrency when I said that using more than one system thread didn't help. I tried varying GOMAXPROCS. It either had no effect or made everything slower. And yes, the defaults for loadtest are useless, they need to run for at least a few seconds.
Your results aren't the same ones I got. Maybe it's different with Go 1.2. I have to go and check.
He wasn't in the office. I'm going to ask him about it today. Like it says at the end of the blog post, if he puts it up on bitbucket I'll include the link.
"the Go implementation was executed with go run ". I think it would be much more appropriate to build the GO script with "go build" and use the resultant binary.
Because the D program was compiled.
The Go version was written by a person enthusiastic and presumably competent in Go. See their perspective here where he concedes defeat on the performance front: http://blog.nella.org/mqtt-code-golf/
Adding C as a baseline is entirely appropriate.
The source code for C, Go, and D is available. The Erlang version may or may not at the discretion of its author.
Probably a more sensible hypothesis is that you like Go and saw a result that is unfavorable to it, so you had an emotional response.
While your "benchmark" (if we should call it that way) obviously make no sense, I would suggest you guys look into how concurrency and parallelism are different concepts.
The key takeaway in the benchmarks seem is that Go is significantly slower than the rest, much much slower.
Apart from the regular 30-sec interval postings on HN extolling the virtues of Go, it seems to me, people should rekindle an interest, or discover a new interest in D, C or Erlang where performance is a consideration, and maybe Go where a need to feel like part of the post-Ruby crowd.
>Go is significantly slower than the rest, much much slower.
Did we read the same article? D was faster than the rest, but Erlang/C/Go were not that far apart, unless its too late in the evening and I'm being stupid.
>Go is significantly slower than the rest, much much slower.
Everyone knows that Go is a new-ish language and has room to improve on performance. That said, Go seems perfectly fast since all of the languages seem to perform fairly well.
Further, were Go "much much slower", CloudFlare, IronIO, Google, etc would probably not be using it...
>discover a new interest in D, C or Erlang
>where performance is a consideration
Go looks to be about ~50% the performance of C++, but, from lots of peoples' comments/writings, is much nicer to write so they use it when productivity is more important than absolute performance.
Note: I'm interested in Go (as I am about lots of languages), but am not a user of it right now.
Ya, Erlang doesn't do well on the Benchmarks Game because the Benchmarks Game doesn't measure communication, which is Erlang's strong point. No-one writes algorithms like those in the Game in Erlang; you code them as a server in C or Java or anything and farm work out to them from Erlang.
The Game is a terrible benchmark for Erlang. Math, computing digits if Pi, string searching, n-body problems. If that is the target domain, don't pick Erlang, or Go, pick Fortran or C.
I don't understand those benchmarks, 'insert any languages' can achieve performances than 99% of companies don't even need. And for the other 1% you're probably smarter than those posts on HN.
Huh, impressive for Erlang, beating a newer, statically compiled language, while being interpreted and with dynamic types.