[Stackless] Planning Stackless Lite

Christian Tismer tismer at stackless.com
Thu Feb 4 21:42:55 CET 2010

Hi Andrew,

--- On Tue, 2/2/10, Christian Tismer <tismer at stackless.com> wrote:
> CT>  This sounds strange without some commentary:
> CT>  PyPy supports soft switching only. This is not a
> CT>  deficiency, but a virtue.
> I wasn't implying that soft switching was a deficiency. Rather I
> thought it would be a benefit. From reading documentation, there is
> an order of magnitude difference in speed between hard and soft
> switching. I thought that even though  PyPy is slower than CPython/Stackless, the soft switching should allow a PyPy programme
> that uses I/O to get comparable performance to its CPython/Stackless counterpart.

Yes, at least. I actually would not wonder if it would outperform
Stackless soft-switching, because the generated implementation
is more sophisticated than the hand-crafted patches used by
Stackless ever can be.
> I am assuming the two major bottlenecks are the context switching and the
> system calls.
> CT>  This soft switching is possible since PyPy has full control
> CT>  over itself. And in this context, things like Greenlets do not
> CT>  exist.
> Okay. I am trying to get a handle on this as a end-user. If I run say
> a simple network test with pypy-c compiled with the --stackless option,
> all other things being equal, I should get comparable performance
> to  a Stackless Python equivalent? I guess I can test this.

This is worth to try, yes.
>> Yes, as an application on top, but that is unrelated.
> CT>  For this soft switching to work, the underlying system must
> CT>  be able to do stack unwinding. When PyPy is translated to C,
> CT>  this is implemented by all the transformations of flow graphs
> CT>  into C routines.
> So greenlets can be taken out of the stackless.py module if one
> is compiling to pypy-c? Again, pardon my lack of knowledge. In this
> context, what are greenlets providing? Does this imply that stackless.py
> needs a minor rewriting?

Yes, greenlets are only there for emulation.  PyPy does not
know about greenlets at all. It just assumes that a few essential
special functions are supported which do the stack handling.
The reason to use greenlets was their ease of use. We did not
want a dependency on Stackless, we needed some independent
context switching engine.
Of course you can remove it from stackless.py, it is for
testing only, without translation.
> CT>  What you are referring to, and that is a unification that I
> CT>  cannot leave leave as is, is the case when PyPy runs on top of a
> CT>  Python interpreter. The Python interpreter must then emulate soft
> CT>  switching, for testing purposes. Exactly for that case
> CT>  using the greenlets for emulation came in handy, just as a
> CT>  surrogate.
> CT>  But this use case of Greenlets has nothing at all to do
> CT>  with PyPy and does not belong to the PyPy world. It is an CT>implementation detail for a feature that seemed impossible to
> CT>emulate for PyPy on top of Python, but it works great.
> I understand. However this capacity, this setup (translate.py or CPython
> with greenlets and stackless.py) works great for prototyping
> features. I think  prototyping features directly in Stackless
> Python (and 'C') would be a rough ride.

Being an extension module is the crucial benefit of greenlet, here.
With Stackless lite, the same thing will be possible.
Prototyping in C is a different story in both cases.

cheers - chris

Christian Tismer             :^)<mailto:tismer at stackless.com>
tismerysoft GmbH             :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key ->  http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
       whom do you want to sponsor today?   http://www.stackless.com/

More information about the Stackless mailing list