Comments on: Stackless Python vs. Go

By: jp

jp — Fri, 10 Sep 2010 08:50:00 +0000

Casomai interessasse: “GCC to merge Go support”

Ciau! ^^

By: sardauker

sardauker — Fri, 10 Sep 2010 22:41:00 +0000

Cominciano ad essere riconosciuti i tuoi meriti:

Google, nel 2010
arriva lo smarthphone
SarÃ venduto online
e senza intermediari
Si chiamerÃ Nexus One. I servizi di telefonia mobile verranno acquistati separatamente

By: Zeno

Zeno — Fri, 10 Sep 2010 07:24:00 +0000

Molto interessante! Certo che Ã¨ raro trovare un linguaggio piÃ¹ lento di python!
Possibile che vogliano sacrificare cosÃ¬ tanto in cambio di una compilazione veloce? A quel punto, perchÃ© non usare un interprete e un lint?

(tra l’altro non avevo ancora sentito parlare di stackless python, direi che ha delle caratteristiche decisamente interessanti, da approfondire)

By: NeXuS

NeXuS — Fri, 10 Sep 2010 16:00:00 +0000

Sorry, but Tasklets and Goroutines are both coroutines, not Green Threads (e.g. a Thread containing only one routine is a coroutine as well).

Tasklets are implemented as Green Threads (they are entirely managed by the Python VM), while Goroutines, as of now, are P-Threads.

I guess the idea for the future is, as you said, to have only a few OS threads and multiplex the Goroutines upon them, but that would require features that are not present in the runtime right now.

By: Johan Carlsson

Johan Carlsson — Fri, 10 Sep 2010 05:05:00 +0000

Tasklets and Goroutines are both green treads (e.g. are lightweight ans scale well compared to OS-level threads) , so there shouldn’t be much difference there.

One thing I suspect might be different is that goroutines are supposted to be distributed over a set of threads, where as tasklets only run in one thread (and also only on one core due to the GIL in Python, which means Stackless wouldn’t scale on a multi core system at all).

Goland manages goroutines and can reallocate goroutines to a different os-thread if one goroutine block (on IO for instance).
This adds could add some overhead.
For what I know Golang doesn’t use this feature yet, since it’s not stable yet. So I’m not sure if it has anything to do with the difference in speed.

Your test with an added load is interesting, because the original test results in just a number of function calls, for which Python could do very well. The biggest difference between Golang and Python is in the typesystem, the intepreter is pretty much the least slow thing for that kind of test.