Re: stackless question

Christian wrote:

> I know you are probably still mad at me about my curt dismissal of your
> class proposal but could you answer one important question about threads
and
> channels before you put me on your kill list?

I'm not mad at all. I don't understand everything, so
I stopped quibbling about classes. For the last two
weeks, I was very busy pushing Stackless to the next
order of madness. I'm trying to make it even faster
than normal Python, and I know now how.

The trick is (probably you knew it before, but I discovered
it by chance): After all my efforts of avoiding using the
C stack, I realized that this was overdone. Due to compiler
layout, the C stack is the ideal cache for local state,
there is no better way to restore information than to return
to a C frame.
Therefore, my "always clear the stack" paradigm made things
slower, since for every return to a function, I have to
restart the frame from its beginning and jump to the
point where I left off. This is no problem for small C
functions which have no state at all, but the interpreter
has quite a lot of variables to restore.

So the idea is: When I am in a place where Stackless should
leave the C stack, I prepare everything necessary to jump
back to the toplevel dispatcher as before.
But then, instead of returning, I can do the call to the
function right in place. If the function returns to me
(that is, it returnes a continuation with me as target),
then it is fine, no jumping necessary. If something else
is the target, I just bubble upwards, and things are done
from toplevel.
This is completely compatible, since the stack does not
contain anything but cached stuff which is also in the frames.
The advantage is, that the cached information can be used
most of the time.
And the reason why this can be faster than normal python
is: There are only the useful C states on the C stack.
All the little preparing functions which Python inserts between
interpreter recursions are already done, they have returned.
As a result, the stack is used more efficiently, giving more
locality of reference, so it should be faster

> My current stackless proposal is at
> http://prothon.org/wiki?pagename=StacklessLanguageFeatures.  It limits the
> use of the threads and channels (what I now call threadMgrs) to the
relation
> that every thread must belong to only one channel at any one time.  Is
this
> going to be a problem?

No, I guess it is a necessary restriction. I did the same.

> If you want to read the proposal and tell me why the whole proposal sucks
> instead of answering this one question that would be great also.

Will try to do this in the night.


begin 666 smile.gif
M1TE&.#EA#P`/`)$!`````+^_O___`````"'Y! $```$`+ `````/``\```(N
MC V9QY$"X6(@6GGJO0!)+3RA$XDA:&Y6JGXMIX$K%G,8^2EE]G:4?&ID%+Y#
#`0`[
`
end