Brief side-experiments: Google Go versus Stackless Python
Google last week released Google Go, a new programming language designed to be “more C-like” (a kind of python/C#/Java mash-up of a language) with support for Erlang’s excellent concurrency management, which allows you to write programs that can do lots of different little things at the same time on machines that have multiple CPU’s. It’s odd that Google that should come out with this at about the same time that I started looking into Python’s high-concurrency variant, Stackless, because both Stackless Python and Go purport to do the same thing: bring high-quality concurrency management to the average developer in a syntax more familiar than Erlang’s, which is somewhat baroque.
While looking through both, I came across Dalke’s comparison of Stackless Python versus Go. Not even taking into account the compile time (which is one of Go’s big features, according to Google), Dalke compared both and found that Stackless Python was faster. His comparison, he wrote, maybe wasn’t valid because the machines on which he ran some of the comparison were close, but not the same.
So, here’s the deal: on a Thinkpad T60, running on the console with no notable load whatsoever, I ran Dalke’s two programs, both of which spin off 100,000 threads of execution and then sum them all up at the end.
The “real” time to run the Go program was 0.976 seconds (average after ten runs). The “real” time to run the Python program was 0.562 seconds (average after ten runs). The Python program, which must make an interpretive pass before executing, was almost twice as fast as the Go program. (It was 1.73 times as fast, which matches up approximately with Dalke’s 1.8).
In fact, you can see the consequences of this in the way the other figures come out: the amount of time dedicated to CPU for both is wildly different. Both spent approximately the same amount of time executing the user’s code (python: 0.496 seconds, go: 0.514 seconds), but time spent by the kernel managing the code’s requests for resources is way off (python: 0.053 seconds, go: 0.446 second).
It may be that Go is simply doing something wrong and this can be fixed, making Go a competitive language. An alternative explanation is that Stackless Python has an erroneous implementation of lightweight concurrency and someday it’s going to be found and high-performance computing pythonistas are going to be sadly embarrassed until they fix the bug and come into compliance with Go’s slower but wiser approach.
But I wouldn’t bet on that.
Kent Beck recently said of Google Wave, “it’s a bad sign for wave that no one can yet say what it is indispensable for. not just cool (it’s definitely that), but indispensable.” The same can be said of Google Go: There’s nothing about it I can’t live without, and other implementations of the same ideas seem to be ahead of the game. Stackless Python not only has Erlang-esque concurrency and reasonable build and execution times, but it has a familiar syntax (which can be easily picked by by Perl, Ruby, and PHP developers), a comprehensive and well-respected standard library, and notably successful deployed applications.