Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Go is pretty slow right now. I wrote a prime number finder in Go and Ruby 1.9 and Ruby smoked it. Granted that's probably mostly due to all the math in Ruby being C, but still, you can't just say that Go is faster because it's compiled before hand.


Honestly, my guess is that you were doing something wrong in the Go code. Go is definitely faster than Ruby, even on a single core machine. http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...


EDIT: haha, thanks so much, guys! Stupid mistake. Go is _significantly_ faster if written properly.

I'd love to know what I screwed up. The results surprised me:

https://gist.github.com/pkulak/99d2d5a5968b5fc03754

https://gist.github.com/pkulak/909d882614e0781e4525

  bender:Desktop phil$ time go run primes.go
  Found them! 78702

  real  0m21.349s
  user  0m21.304s
  sys 0m0.033s
  bender:Desktop phil$ ruby -v
  ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-darwin11.4.0]
  bender:Desktop phil$ time ruby primes.rb
  Found them! 78702

  real  0m7.656s
  user  0m7.651s
  sys 0m0.005s
  bender:Desktop phil$ time go build primes.go

  real  0m0.269s
  user  0m0.231s
  sys 0m0.033s


You're using integer arithmetic in Ruby and floating-point arithmetic in Go. Try replacing

  math.Mod(float64(i), float64(j))
with

  i%j
My results:

  $ time go run primes.go
  Found them! 78702

  real	0m0.835s
  user	0m0.787s
  sys	0m0.039s

  $ time ruby primes.rb
  Found them! 78702

  real	0m21.013s
  user	0m21.005s
  sys	0m0.016s


It's worth noting that the time on the go side includes the time to run the compiler, and linker, since you're using `go run`, instead of `go build`. Not saying that's bad, just something to keep in mind when benchmark numbers are in the second range.

(I understand that you did because the original poster did it)


You should use the same integer remainder operator (%) as in the Ruby version instead of math.Mod(float64(i), float64(j)):

  <...>
		for j := 2; j < limit; j++ {
			if i % j == 0 {
				found = true
  <...>


I assume you're comparing the relative performance of their bignum libraries? If so, that's not exactly a representative comparison.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: