Is Stackless Python DEAD?

[Christian Tismer]

Martin von Loewis wrote:

> Michael Hudson <mwh at python.net> writes:
> 
> 
>>>- it adds 17 new members to the frame object, doubling the number
>>>  of members. Usage of some of these members isn't obvious to me.
>>>
>>See below about map & friends.
>>
> 
> If they are all just for the variables in map etc., a better solution
> must be found - don't think it is desirable to have them in every
> frame, if they are just used inside map.


They were also heavily used in the continuation code.
I wanted to add a number of registers, which are used in
the manner an extension needed it, without doing a redesign
of frames (which breaks compatibility).

> However, from inspecting the patch, I doubt this is the case. Some of
> them are general-purpose, but I couldn't easily figure out what, for
> example, this first-instruction business is good for.


Some fields are not necessary, after all.
This is evolution in flux ... :-)

>>So when map wants to call the Python function, it needs to stuff all
>>the local data it cares about into a frame object (see above), push
>>this frame object onto the (Python) stack, *return* to the interpreter
>>in such a way that the mapping function is called next and then every
>>time(!) that returns have the interpreter call back into map again.
>>
> 
> Why couldn't map behave as if it was a plain Python function,
> implemented as
> 
> def map(fun,args):
>   res = []
>   for a in args:
>     res.append(fun(a))


It does so.

> [I know that map is implemented in a more-involved way; it should
> still be possible to find its Python equivalent, then think how
> stackless would execute this equivalent]
> 
> For the additions to frame_state, that would mean that map should
> reserve a number of localsplus variables, instead of outright adding
> to frame_state on the C level.


I wanted map to be as efficient as before, so I needed some
integer registers, not Python objects.
No, I would propose to extend frames to also support memory
which doesn't need to hold Python objects. That makes them
general-purpose.

>>>- The code adds PREPARE macros into each branch of ceval. Why?
>>>- It adds a long list of explicitly not-supported opcodes into
>>>  the ceval switch, instead of using 'default:'. No explanation
>>>  for that change is given, other than 'unused opcodes go here'.
>>>  Is it necessary to separately maintain them? Why?
>>>
>>This was an optimization Chris used to try and get back some of the
>>performance lost during the stackless changes.  IIRC, he handles
>>exceptions and return values as "pseudo-opcodes" rather than using the
>>WHY_foo constants the current ceval.c uses.  I never really understood
>>this part.
>>
> 
> If it is an optimization, I think we should take a step back and first
> try to understand what it tries to optimize, and how it does
> that. Perhaps we find that it isn't needed at all, and that the
> problem could be solved in a different way. If you don't understand
> it, it can't go into Python.


Please, these optimizations should be kept out of Stackless
discussion. As you might have noticed by looking into the
source tree, there is a file named ceval_pre.c which does
not have these optimizations. You can compile it instead of
ceval.c and get the same (slower) functionality.
I always work with this file when I change Stackless. As a part
of the build step, I run the script cevalpatch.py, which scans
the source and applies the optimization patches. So why care.

>>I think integrating stackless into the core is a fairly huge amount of
>>work.  I'd like to think I could do it, given several months of
>>full-time effort (which isn't going to happen).  About the only likely
>>way I see for it to get in is for it to become important to Zope
>>Corp. for some reason, and them paying Tim or Guido (or Chris) to do
>>it.
>>
> 
> I don't think these are the options. I don't volunteer to support this
> code myself, either, but if somebody would step forward and claim that
> she understands it all, and is willing to present it to Guido in a way
> that he understands it also, and if all the hackish parts of it would
> be replaced by understandable code, I think it could go into Python.
> It just needs a determined volunteer to work on it.


Turns out that I will have to try it.

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net/
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
      where do you want to jump today?   http://www.stackless.com/