[Stackless] Questions and Advice for Upcoming Talk
andrewfr_ice at yahoo.com
Sun Apr 25 16:10:57 CEST 2010
>I was thinking that the big (as in really big) leg up that Go has on
>Stackless is the fact that Go can take advantage of multiple cores on the
>same machine or even multiple machines working together without writing >your own load-balancing and etc and what-have-you, which would be a major >leg up over pretty much every language currently in existence.
>Would it make a difference if Dalke's goroutines were running on an 8 core
>processor rather than a single core? Stackless has the advantage of having
To the best of my knowledge, the current implementation of Go does not
support multiple cores by default (read transparently). There is a runtime feature runtime.GOMAXPROCS(NCPU) to tell Go about other CPUs. Again, I do little programming that requires multiple CPUs.
The focus of my talk isn't about comparing the merits of Go to Stackless Python. Rather I am interested in the idea of using Python to prototype. In this case, it is using Python to prototype a new feature Stackless Python feature, select. Select is non-trivial (and I think my implementation's optimization got it wrong so I have to work on that before tomorrow. Grrrghh). And yes I could use a variation of it. The secondary idea is Stackless's takes a toolbox approach to building concurrency mechanisms. A little bit of C Stackless Python would have to be changed. However most of the heavy lifting is done by the Stackless API. To me that says a lot. This is where comparing the differences in APIs and approaches comes in. Here I am expanding on Richard Tew. Forget select for a moment. There are examples I have from my WS-BPEL experiences (i.e., Pick) which are easy to code in Stackless but would be difficult to code in Go.
I am treating all this as a learning experience. It is also getting me to look at C again (man am I rusty).
More information about the Stackless