[Stackless] Questions and Advice for Upcoming Talk
tutt.andrew at gmail.com
Sun Apr 25 11:25:59 CEST 2010
I just read the Dalke diary entry and I have a question.
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
no thread overhead whatsoever because it doesn't deal in system threads like
Go does, and on a single core couldn't that make all the difference?
More importantly, wouldn't he have wanted to choose an example where a total
solution could be built by passing partially completed pieces of a solution
between thousands of independently executing routines? Isn't that what Go
was built to do? Of course, I have not read the Go specification. I thought
the whole point of Go was parallel processing and computing, which Stackless
isn't made to do anyway.
On Sun, Apr 25, 2010 at 12:00 AM, Andrew Francis <andrewfr_ice at yahoo.com>wrote:
> Hi Folks:
> I just finished a new version of my implementation of select (I actually
> call it an eventHandler) using stackless.py. Let me write some more tests
> and examples before posting. I don't think I will have time to implement the
> minimal hooks in C Stackless Python by Monday. Now time to write slides. I
> would like to solicit my fellow Stackless Pythonistas for some advice.
> Anyhow, I believe Richard in his blog, discusses the difference in approach
> between Stackless and Go. It seems to me that Stackless by
> exposing more of the scheduler to the programmer, is promoting a tool box
> approach - if you don't like the way the scheduler works, there is enough
> API and classes to do what you want in a module. Also Stackless is more
> trusting and puts more responsibility on the shoulders of the programmer. I
> haven't written any serious Go programmes yet but Stackless seems to me more
> flexible. Does this seem to be a reasonable assessment of Stackless
> The other thing in the Pike paper and in Go, is the attempt to put a
> certain amount non-determinism into the system, to prevent programmers from
> manipulating the system. On the other hand, from reviewing Kristjan's EVE
> talk, fairness (tasklets run in the order that they are ready) seems to a
> very important concept in Stackless design. Again, would this be an accurate
> As for the direction of Stackless? I will assume with integration with
> Psyco, this will be one less reason to write C extensions?
> Any other comments?
> I will probably ask similar questions in the Go mailing list.
> Stackless mailing list
> Stackless at stackless.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Stackless