[Stackless] Planning Stackless Lite
tismer at stackless.com
Thu Feb 4 21:42:55 CET 2010
--- 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