5 ms·

Migrated WordGap from Python to Go 1

50 points by voidlogic 14y ago

NateDad 14y ago
And the app engine only supports a single thread for Go, imagine if you could make it multi-threaded.
- phasevar 14y ago
  Multi-threaded wouldn't help the case of a single request, which is what this post is reporting latency numbers on.
  - voidlogic 14y ago
    True, but it would help average request latency under load. I am hoping with Go 1.1 RC coming out next month that Google might enable multi-threading on the GAE. Note: Even with Go only given a single core a developer can still write a Go program so they are concurrent. That way when one goroutine blocks on IO, another can use the CPU to make progress; furthermore, when multi-threading is enabled the performance upgrade will be substantial and seamless.
  - Encosia 14y ago
    Assuming he's searching a trie to build the list of anagrams, he could distribute a single request's work over a thread per letter.
    - Evbn 14y ago
      If he has multi core, which is often missing in a VM.
viraptor 14y ago
I'd like to see the before and after code. Such difference is not impossible between languages, but it's possible that a better implementation/algorithm in the original code wouldn't bring a similar speedup...
- voidlogic 14y ago
  "Such difference is not impossible between languages" You are correct in wanted to make sure the algorithms and data-structures used still have the same run-time complexity. But saying this is impossible is not accurate. This kind of difference is not uncommon when BOTH the before and after program optimally handle IO (network,file,db,etc), BUT the before program is from the interpreted performance tier (PHP,Perl,Ruby,Python) and the after program is from the compiler tier (C/C++,Java,C#,Go,Scala,Haskell). These micro-benchmarks, while not proving anything, at least suggest that you could be wrong as well: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=python3 http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
  - viraptor 14y ago
    We're in a complete agreement. As I wrote: "Such difference is -not- impossible between languages" :) I just find it rather unlikely.
    - voidlogic 14y ago
      You find it unlikely that a compiled language might be 15x faster than a interpreted language doing a compute-bound workload, when said compiled language is often 30x faster in posted synthetic benchmarks... I think you are extremely skeptical... I have ported node.js applications to Go and seen similar substantial speedups. In my cases though I was running in a multi-threading enviroment. not GAE and the performance difference (improvement) was much greater under concurrent load versus single request latency. But that seems reasonable since node.js is closer to Go in performance than Python is. I guess I just believe it because I have seen it. :)
      - igouy 14y ago
        >>posted synthetic benchmarks<< The benchmarks game shows toy programs not synthetic benchmarks ;-)
    - drivebyacct2 14y ago
bsaul 14y ago
Rewriting any code in any language pretty much always show improvements. Unless we're sure it's not a different data structure or algorithm it doesn't mean that much.
- kkowalczyk 14y ago
  Except it doesn't, not when improvement is so dramatic. If he rewrote Python in Ruby, the perf would have been more or less the same. If he rewrote in C, he would get even better perf but at much bigger cost (in dev time). The point of his article is that Go is almost as easy to write in as Python but gives you 10x perf and that's why Go is attractive. It has the right perf/coding effort ratio.
  - Evbn 14y ago
    This comment is making the exact mistake that parent was concerned about.
  - bsaul 14y ago
    i understand what you're saying, but my point is that even rewriting from python to python would show improvement. i've just coded the same project three times in different languages last year, and my design is getting better every time, and it has (almost) nothing to do with the language themselves. a benchmark is a much more reliable thing if you want to compare relative speed. or a "pet store" app. but not a "real world" project. altough that's still a really nice experience to read about.
waterside81 14y ago
We're going through the same thing right now. Porting a few thousand lines of Python to Go. It's almost a line for line port, with the odd exception here or there. One thing I really miss going to Go from Python is using getattr or dict.get(some_key, default_value). Also tuples. And marshalling from a JSON blob is kind of a pain in Go. In fact, I started making a list of things Python devs need to know about when switching to Go. It's all a tradeoff, you lose some expressiveness for performance.
- swaroop 14y ago
  Please do post the list of things you mentioned in your second paragraph.
- georgemcbay 14y ago
  You can do a sorta-like getattr in Go using reflect, though I'm not sure exactly what your use case is. Fields need to be exported (upper-case names) though: http://play.golang.org/p/XPgHkKCz_D http://play.golang.org/p/XPgHkKCz_D But you're absolutely right, you trade in some easy expressiveness and lack of boilerplate for better performance and easy concurrency. But Go is much better about the boilerplate required than most other static/compiled languages, IMO.
  - waterside81 14y ago
    I like your solution but that's kind of the rub about Go, at least at this stage of its still-early life. You have to re-invent the wheel a lot. It's frustrating to have to implement things that you know exist elsewhere, especially things like collections.defaultdict in Python. Agree re: boilerplate. Much slimmer than Java or C++. And the build times, my God, the build times. It almost makes up for not having a true REPL.
- earthboundkid 14y ago
  If the original Python is d[key] = d.get(key, 0) + value, in Go it can be replaced with m[key] += value, since the default value for a map[string]int value is 0. This doesn't totally replace the need for defaultdicts, but it should greatly lessen it.
kristianp 14y ago
It would have been useful if there were some implementation detail. Did he go from hashes in python to maps in go? Or switch to maps of structs for example?
tansey 14y ago
If WordGap was written in pure Python, without the use of any matrix libraries like numpy/scipy, then I think you could have done better. 7x speedup is actually pretty low for algorithms that I've rewritten to use numpy.
pjmlp 14y ago
It seems that Go is killing Python and Ruby projects instead of the languages the original authors thought of. While in the enterprise everyone is happy using the available set of languages, on HN we continuously see posts about migrations from Ruby/Python to Go.

50 points by voidlogic 14y ago

NateDad 14y ago

And the app engine only supports a single thread for Go, imagine if you could make it multi-threaded.

phasevar 14y ago
Multi-threaded wouldn't help the case of a single request, which is what this post is reporting latency numbers on.
- voidlogic 14y ago
  True, but it would help average request latency under load. I am hoping with Go 1.1 RC coming out next month that Google might enable multi-threading on the GAE. Note: Even with Go only given a single core a developer can still write a Go program so they are concurrent. That way when one goroutine blocks on IO, another can use the CPU to make progress; furthermore, when multi-threading is enabled the performance upgrade will be substantial and seamless.
- Encosia 14y ago
  Assuming he's searching a trie to build the list of anagrams, he could distribute a single request's work over a thread per letter.
  - Evbn 14y ago
    If he has multi core, which is often missing in a VM.

viraptor 14y ago

I'd like to see the before and after code. Such difference is not impossible between languages, but it's possible that a better implementation/algorithm in the original code wouldn't bring a similar speedup...

voidlogic 14y ago
"Such difference is not impossible between languages" You are correct in wanted to make sure the algorithms and data-structures used still have the same run-time complexity. But saying this is impossible is not accurate. This kind of difference is not uncommon when BOTH the before and after program optimally handle IO (network,file,db,etc), BUT the before program is from the interpreted performance tier (PHP,Perl,Ruby,Python) and the after program is from the compiler tier (C/C++,Java,C#,Go,Scala,Haskell). These micro-benchmarks, while not proving anything, at least suggest that you could be wrong as well: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=python3 http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
- viraptor 14y ago
  We're in a complete agreement. As I wrote: "Such difference is -not- impossible between languages" :) I just find it rather unlikely.
  - voidlogic 14y ago
    You find it unlikely that a compiled language might be 15x faster than a interpreted language doing a compute-bound workload, when said compiled language is often 30x faster in posted synthetic benchmarks... I think you are extremely skeptical... I have ported node.js applications to Go and seen similar substantial speedups. In my cases though I was running in a multi-threading enviroment. not GAE and the performance difference (improvement) was much greater under concurrent load versus single request latency. But that seems reasonable since node.js is closer to Go in performance than Python is. I guess I just believe it because I have seen it. :)
    - igouy 14y ago
      >>posted synthetic benchmarks<< The benchmarks game shows toy programs not synthetic benchmarks ;-)
  - drivebyacct2 14y ago

bsaul 14y ago

Rewriting any code in any language pretty much always show improvements. Unless we're sure it's not a different data structure or algorithm it doesn't mean that much.

kkowalczyk 14y ago
Except it doesn't, not when improvement is so dramatic. If he rewrote Python in Ruby, the perf would have been more or less the same. If he rewrote in C, he would get even better perf but at much bigger cost (in dev time). The point of his article is that Go is almost as easy to write in as Python but gives you 10x perf and that's why Go is attractive. It has the right perf/coding effort ratio.
- Evbn 14y ago
  This comment is making the exact mistake that parent was concerned about.
- bsaul 14y ago
  i understand what you're saying, but my point is that even rewriting from python to python would show improvement. i've just coded the same project three times in different languages last year, and my design is getting better every time, and it has (almost) nothing to do with the language themselves. a benchmark is a much more reliable thing if you want to compare relative speed. or a "pet store" app. but not a "real world" project. altough that's still a really nice experience to read about.

waterside81 14y ago

We're going through the same thing right now. Porting a few thousand lines of Python to Go. It's almost a line for line port, with the odd exception here or there. One thing I really miss going to Go from Python is using getattr or dict.get(some_key, default_value). Also tuples. And marshalling from a JSON blob is kind of a pain in Go. In fact, I started making a list of things Python devs need to know about when switching to Go. It's all a tradeoff, you lose some expressiveness for performance.

swaroop 14y ago
Please do post the list of things you mentioned in your second paragraph.
georgemcbay 14y ago
You can do a sorta-like getattr in Go using reflect, though I'm not sure exactly what your use case is. Fields need to be exported (upper-case names) though: http://play.golang.org/p/XPgHkKCz_D http://play.golang.org/p/XPgHkKCz_D But you're absolutely right, you trade in some easy expressiveness and lack of boilerplate for better performance and easy concurrency. But Go is much better about the boilerplate required than most other static/compiled languages, IMO.
- waterside81 14y ago
  I like your solution but that's kind of the rub about Go, at least at this stage of its still-early life. You have to re-invent the wheel a lot. It's frustrating to have to implement things that you know exist elsewhere, especially things like collections.defaultdict in Python. Agree re: boilerplate. Much slimmer than Java or C++. And the build times, my God, the build times. It almost makes up for not having a true REPL.
earthboundkid 14y ago
If the original Python is d[key] = d.get(key, 0) + value, in Go it can be replaced with m[key] += value, since the default value for a map[string]int value is 0. This doesn't totally replace the need for defaultdicts, but it should greatly lessen it.

kristianp 14y ago

It would have been useful if there were some implementation detail. Did he go from hashes in python to maps in go? Or switch to maps of structs for example?

tansey 14y ago

If WordGap was written in pure Python, without the use of any matrix libraries like numpy/scipy, then I think you could have done better. 7x speedup is actually pretty low for algorithms that I've rewritten to use numpy.

pjmlp 14y ago

It seems that Go is killing Python and Ruby projects instead of the languages the original authors thought of. While in the enterprise everyone is happy using the available set of languages, on HN we continuously see posts about migrations from Ruby/Python to Go.