On Apr 14, 2014, at 9:44 AM, Kristján Valur Jónsson <krist...@ccpgames.com> wrote:
> Hi there. > > I'm not entirely sure about the benefit of such a re-architecture. > As I see it the chief benefits of Stackless over greenlets, are: > 1) Pickling of runtime state. > 2) Scheduling and higher level primitives implemented in C > 3) "stackless" excecution of certain builtin python things. (soft switching > as opposed to stack slicing) . Allows for example soft stack switch in an > __enter__/__exit__ method (an experimental feature). Soft switching > primarily allows tasklet state to be pickled and restored, but it is > supposedly also for performance of execution of regular python code (this > last claim is unproven) I figure you should consider it “anecdotal”, but for my use (lots of relatively “parallel” pure-python tasklets with messaging between them to implement an asynchronous event-based scripting environment), the performance benefits (cpu as well as heap footprint) of soft-switching over stack slicing are quite profound. > If we didn't need either, we could implement stackless as a .py module that > relies on greenlets. Then "stackless" would be just another greenlet client. > Pickling can certainly be implemented in a more slim implementation, but > picling of an execution state relies on "soft" switching. > Reasoning about the performance is harder but we always want to be fast :) > > So, what can we throw away and how can we restructure to make things simpler, > while keeping the essential benefits of stackless? > > > > -----Original Message----- > From: stackless-boun...@stackless.com > [mailto:stackless-boun...@stackless.com] On Behalf Of Alain Poirier > Sent: 13. apríl 2014 16:08 > To: stackless@stackless.com > Subject: [Stackless] Sprinting at PyCon > > Hi all, > > I would like to discuss how it'd be possible or not for Stackless to follow > the same path than PyPy: > > - A simpler Stackless core, with only the 'tealet' / '_continuation' stack > switch, writing in C. Exposing the same API than PyPy. > IIRC, Krisjan already has such a Stackless version. > > - All the high level features of Stackless like Tasklets and Channels moved > to > the 'stackless.py' pure Python module. > > - An emulation of the greenlets API, in a 'greenlet.py' pure Python module. > > - Bonus point if these 'stackless.py' and 'greenlet.py' modeules are shared / > co-developed with the PyPy project :) > > I see several advantages then: > > - Greenlets and Stackless features being Python modules, easier > experimentations > are possible. For example writing other scheduling policy or higher > concurrency > primitives such like Andrew's select/join. > > - With a 'greenlet.py' compatible module, lots of softwares like 'gevent' > could > work without any modification. > > - Works on 'greenlet.py' and 'stackless.py' can profit both to Python > Stackless > and PyPy. > > Just my 2 cents, > Alain > > > _______________________________________________ > Stackless mailing list > Stackless@stackless.com > http://www.stackless.com/mailman/listinfo/stackless > > _______________________________________________ > Stackless mailing list > Stackless@stackless.com > http://www.stackless.com/mailman/listinfo/stackless > _______________________________________________ Stackless mailing list Stackless@stackless.com http://www.stackless.com/mailman/listinfo/stackless
