Hacker News Reader

Comment by voidlogic | Hacker News Reader

Since the author uses Go as a basis of comparison. I thought these benchmarks from The Computer Language Benchmarks Game might be interesting:

Go vs. Ruby: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

Go vs. Python: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

Note: These results are from the 64-bit single core machine since it has already been updated to Go 1.1 beta 1. There is also a faster Go regex program (#7) that hopefully can be made to work again after 1.1 is released (in place of #1).

Although still using Go 1.0.X ,the recent TechEmpower benchmarks might be interesting if you have not seen them: http://www.techempower.com/blog/2013/03/28/framework-benchma... (It looks like Go 1.1 might be 3x faster: https://gist.github.com/errnoh/5320784)

P.S. As always your own program is always the best benchmark to use, your millage may very, take your gain of salt, etc etc.

View on HN

Probably worth noting that the presentation that the author is discussing is less about 'which language is faster' and more about what sort of abstractions different types of languages encourage.

The presenter explicitly takes the position that Go and Python (actually PyPy) should be equally fast given the same sort of operations. Just that Python's idioms tend to be less efficient. He's a PyPy developer too, so I would think he would know something about what's going on under the hood. (He also talks a bit about why the VM doesn't/shouldn't try to optimize these cases automatically. Worth a look, it isn't long.)

Good summary. But I disagree with the author that immutable strings and ubiquitous hashes are merely unfortunate idioms of python - to me python is about simplicity, and those things are what make python conceptually simple. I don't have to worry about clobbered buffers, nor about datastructure semantics besides simple hashes.

The performance impact of the hashes is bad enough that people tweak designs in most unfortunate ways...

I think a case can be made that it is more important that the solution be simple and clean.

On the same site, the advantages of Go vs good dynamic language implementation like JavaScript V8 aren't so impressive:

http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

Being 2-10x faster and using a lot less memory isn't impressive? I'm sure the Go optimizer still needs a lot of work. It's going to get much better. The V8 optimizer is great but we're probably closer to the limit of how much more can be done than with Go.

I think there's a bit of a disconnect here between people who work on applications where, say, a 25% reduction in CPU usage would be a big win, and people who don't worry about performance as long as their cluster isn't melting down.

Those results are from the x86-64 machine with one core (because the multi-core 64-bit machine is still running Go 1.0.3). Once Go 1.1 is realized and the multicore machine is updated, run the comparison again there. Javascript fairs even worse against Go when multiple cores are available. Gos support for parallel processing blows JS away.

Reply on news.ycombinator.com