Hi Andrew,
--- On Tue, 2/2/10, Christian Tismer <[email protected]> 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:[email protected]>
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/
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
