16Nov

Brief side-experiments: Google Go versus Stackless Python

Posted by Elf Sternberg as programming, 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.

6 Responses to Brief side-experiments: Google Go versus Stackless Python

Steve Howell

November 16th, 2009 at 1:03 pm

Go seems like Google Wave in that it has nothing indispensible, or nothing that has been done before, but if they get it right, maybe they will at least have something that no single other tool provides. For example, Stackless Python does not provide a static typing system. Now maybe that’s a dubious advantage of Go over Stackless Python, but static typing support might matter for some people (maybe more in terms of perceived “safety” of the code than actual performance). Of course, there have been efforts during various times in Python’s history to augment Python with static typing hints…

Ten

November 16th, 2009 at 11:05 pm

Man, what’s with everyone hating on Google Wave? Seriously, get over it. Wave is absolutely amazing and no, nothing has been done like wave before. To suggest there has been is complete nonsense.

As for Google’s Go! language, it’s still very, very early to really judge it’s performance against mature (or relatively mature) languages such as Python. Man oh man.. get over it. Wait for an official, stable release before jumping the damn gun!

Brief side-experiments: Google Go versus Stackless Python | Elf … MoinMoin Wiki

November 17th, 2009 at 1:45 am

[...] from:  Brief side-experiments: Google Go versus Stackless Python | Elf … By admin | category: python | tags: computer-overclocking, filling-the-field, [...]

Thijs (Shenzhen)

November 17th, 2009 at 8:48 am

From what I read on HackerNews, it turns out that the Stackless benchmark is single-threaded. Go is probably spending quite a lot of time on managing the threads, migrating stuff or locking. Go’s implementation will become faster probably, but even then you shouldn’t compare it to Stackless. Better compare to Erlang then…

Elf Sternberg

November 17th, 2009 at 11:26 am

Ten, I think the issue with Wave is that nobody can really say what it’s for, yet. Try to look at Wave from the consumer or business user’s point of view, and tell me what it does that you can’t do some other way, then tell me why I should do it the Wave way.

Elf Sternberg

November 20th, 2009 at 12:21 pm

Thijs: I have to agree, and that’s disappointing. What this proves is that Stackless is a smart implementation of a single-core multiplexing piece of code, but still isn’t going to get out of that core anytime soon.

What is it with Python heading down the Hurd rathole?

Comment Form

Recent Comments