Re: stackless implementation (was Re: New stackless proposal)

Mark Hahn wrote:
> Christian Tismer wrote:
> 
>>[consumer/producer, who is on the stack]
>>
>>>My proposal has the implementation that explains the answer to your
>>>questions.  The first next() call creates and calls the generator
>>>thread and then calls yield to get the first value.  Niether thread
>>>will have to reconstruct any stack state.  Both threads will have
>>>their own stacks existing the whole time they run.  The generator
>>>stack will run until it terminates and then it's stack will be
>>>destroyed.  The calling stack will be the normal stack that exists
>>>before and after the gen is used.
>>
>>Ah, oh! I did not expect that you are doing assembly tricks.
> 
> Assembly tricks?  We have a big communication problem here.  My stacks are
> just  linked lists of  Prothon frames.  There is no C stack involved.  Why
> would there be any assembly code involved?

Whoops! You were talking of stacks which are not C stacks.
I didn't realize that.
No, I was talking about C stacks, and if you allow part
of your objects to be still there, when another one runs.
This is what I just did as an optimization.
Most probably totally unrelöated to Prothon.

> OH!  I keep forgetting the restriction that a Thread being used as a
> co-routine can't call a C extension.  I need to put this in the proposal.
> There must be only one Thread that is the main Thread that can have the C
> stack intermixed and never terminates.  Damn, this is getting messy.

Ok. And I started to think that you allocate a little new C
stack for your functions. Sorry about that, WRONG :-)

>>>My proposal DOES have two stacks and a real switch.  Each thread has
>>>its own stack and the threadMgr is a real switch.  What can I do to
>>>explain my implementation better?

 From the above, isn't it easy to deduce that you are talking of C
stacks, especially if there is a "real switch". That's how it came.

> How does your stackless implement the multiple tasklets?  Does it allow C
> extensions in a tasklet?

Yes, sure. It doesn't like it very much, things become slower,
assembly is involved, but it works.
If this is not necessary, everything is done by stack avoidance,
no assembly.

Ok, let me start over:

My own quibbling about optimization stuff was related to
my observation that Stackless is a little bit slower than
normal Python.
One reason is that I really have to check some more things,
the other reason is that I have to re-enter the Python
interpreter more often.
When one Python function calls the other one, then one C
interpreter calls the other one. The suspended one will
start off where it called.
Not so in Stackless: I always have to start over from the
beginning, because the C stack is not used.
This is what I tried to change, with a little win, of course.
Now I can use the C stack, like a cache, that makes things
faster. It is faster to load the registers from the C stack.
But at any time, I can clear the stack and continue like
before.
This all only pays off for very few, short frames involved,
which are running in a tight loop between tasklets. Then,
tasklet channel transfers are twice as expensive as a yield
statement. But technically, I must be able to almost reach
yield's speed, so I can arrange things into a similar
scenario: One frame can stay on the stack, like with generators.

Please feel free to ignore this stuff completely, it is just my
personal tick to optimize an implementation which started
wrong from the ground. :-)

ciao - chris

-- 
Christian Tismer             :^)   <mailto:[email protected]>
Mission Impossible 5oftware  :     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 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/