[Stackless] Multi-CPU Actor Based Python
glavoie at gmail.com
Wed Nov 19 17:51:07 CET 2008
I really find this discussion interesting because it's somewhat related
to my university master degree project at Université Laval, Québec, QC,
Canada. Right now, I'm working on a simple way to extend channel
communication between different Python VM. My work probably isn't really
efficient for now but I want first to have a concept in place that works,
then optimizations will come after. Also, I want to support my communication
model with process algebra where programs correctness can be verified in a
theorical way. For my project, I now work with PyPy's stackless
implementation because I really like the fact that it's coded in Python and
it's really easy to extend. I also plan to port my project to Stackess once
it's completely working but for sure, I'll probably need some help for that.
If someone are interested by such a project, I have some more things I want
to put together to have enough material for the thesis but at some point,
help from the community could be appreciated.
Thanks for reading me!
2008/11/19 Larry Dickson <ldickson at cuttedge.com>
> The key word ought to be "stackless" as in "Stackless Python." The
> Transputer and occam people showed long ago that multiprocessing (which is
> what you are really talking about here) as well as multitasking become
> really easy (i.e. overhead of a dozen cycles or so) if you get rid of
> implicitly shared resources like stack. You can still do stacky things that
> just take a moment (e.g. "soft interrupts") but very frequently you come up
> for air which means your stack depth goes to 0 and then you can do all the
> comms and context switching you want.
> If Stackless lives up to its name, it should be very easy to get multiple
> VMs talking to each other. You just treat their comms as external comms and
> extend the local tasklet response to socket-like things as we were talking
> about in the earlier thread. Then the VMs themselves, obviously, must not
> share resources, or if they do, there must be very strict design control at
> that point.
> Larry Dickson
> On 11/19/08, Timothy Baldridge <tbaldridge at gmail.com> wrote:
>> What I'm more looking to reduce, is the overhead of transferring data
>> from one Python VM to another. In current implementations transferring
>> data from one VM to another requires pickling data (and that requires
>> traversing the entire object being transmitted, pickling each part
>> along the way), transmitting it across the wire, then unplickling it
>> at the other end. So where talking thousands of cycles.
>> In the method I'm proposing, you could have multiple "VMs" in the same
>> process, with a unified GC, these VMs would would share nothing. If
>> all messages are immutable, then all that is required is to copy a
>> pointer from one VM to the other and increment the GC ref count on the
>> message. That's what, 100-200 cycles or so (yes I did just pull that
>> out of the air).
>> My core idea here is that multitasking in modern languages isn't as
>> pervasive because of the overhead/risks involved. In C you have shared
>> memory issues. In Erlang, well, many people can't stand the Erlang
>> syntax. And in Python you can't have to pass messages via
>> So does anyone else see this being possible, or am I off my rocker?
>> Stackless mailing list
>> Stackless at stackless.com
> Stackless mailing list
> Stackless at stackless.com
glavoie at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Stackless