3 ms·

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: ht

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?test=all&lang=go&lang2=yarv http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te... Go vs. Python: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=python3 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-benchmarks/ 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 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.

yew 14y ago
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.)
- ealloc 14y ago
  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.
  - cbsmith 14y ago
    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.
acqq 14y ago
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?test=all&lang=go&lang2=v8 http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
- melling 14y ago
  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.
  - army 14y ago
    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.
- voidlogic 14y ago
  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.

yew 14y ago

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.)

ealloc 14y ago
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.
- cbsmith 14y ago
  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.

acqq 14y ago

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?test=all&lang=go&lang2=v8 http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

melling 14y ago
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.
- army 14y ago
  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.
voidlogic 14y ago
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.