http://www.stackless.com/

http://www.stackless.com/spcpaper.htm

Continuations and Stackless Python:

"Instead of a direct implementation of coroutines and generators (as C extensions), I decided to use the most general approach: Implement continuations as first class callable objects, and express generators and coroutines in Python."

In article <buempb$139g$1@digitaldaemon.com>, nobody@no.where says...
>
>http://www.stackless.com/ http://www.stackless.com/spcpaper.htm

The spcpaper was pretty deep stuff. I ended up gawking it in awe.

Until I remembered how I felt when I studied my first computer. (Which I learnt throug-and-throug!) The concept of having one single stack for the entire machine (bios,os,basic,user programs, all using the same stack) seemed thoroughly preposterous.

But that was 20 years ago. Since then I've gotten so used to the stack concept that I hardly see it anymore, like the air around me. And I guess everybody here feels the same?

Then this stackless stuff pops up, and again I'm breathless.
To use it, I guess, one has to unlearn 20 years' worth of
stacking. But the rewards may be huge for some sorts of programs.
I think this is like OO, recursion, coroutines, etc., where
it does take some time before you get a clear picture of what
they could/should be applied to.

If you really can turn a language stackless without breaking existing programs, then I would't be surprised if D 2.0 suddenly turns stackless one day!

Incidentally, I vote for not trying this before March!   :-)

I'm a fan of Stackless Python too.  It has changed a lot since that paper was written, though.

Stackless still has a stack; it's just that the Python stack is decoupled from the C stack.  This does make some things easier, but it is not really all that different from Win32 Fibers, in which the "C" stack can be decoupled from the OS thread's default stack.

"Georg Wrede" <Georg_member@pathlink.com> wrote in message news:buh4fj$234j$1@digitaldaemon.com...
> In article <buempb$139g$1@digitaldaemon.com>, nobody@no.where says...
> >
> >http://www.stackless.com/ http://www.stackless.com/spcpaper.htm
>
> The spcpaper was pretty deep stuff. I ended up gawking it in awe.
>
> Until I remembered how I felt when I studied my first computer. (Which I learnt throug-and-throug!) The concept of having one single stack for the entire machine (bios,os,basic,user programs, all using the same stack) seemed thoroughly preposterous.
>
> But that was 20 years ago. Since then I've gotten so used to the stack concept that I hardly see it anymore, like the air around me. And I guess everybody here feels the same?
>
> Then this stackless stuff pops up, and again I'm breathless.
> To use it, I guess, one has to unlearn 20 years' worth of
> stacking. But the rewards may be huge for some sorts of programs.
> I think this is like OO, recursion, coroutines, etc., where
> it does take some time before you get a clear picture of what
> they could/should be applied to.
>
> If you really can turn a language stackless without breaking existing programs, then I would't be surprised if D 2.0 suddenly turns stackless one day!
>
> Incidentally, I vote for not trying this before March!   :-)
>
>

I'm just trying to inform Walter the possible options to implement coroutine/generator/continuation in D (if he doesn't know it already).

Georg, as long as you keep your mind open, you will see the light :-) it's not that deep at all.

Bruce, you said it has changed a lot, can you provide a pointer?  I didn't follow Stackless Python very closely.


In article <buh8td$2a4h$1@digitaldaemon.com>, Bruce Dodson says...
>
>I'm a fan of Stackless Python too.  It has changed a lot since that paper was written, though.
>
>Stackless still has a stack; it's just that the Python stack is decoupled from the C stack.  This does make some things easier, but it is not really all that different from Win32 Fibers, in which the "C" stack can be decoupled from the OS thread's default stack.
>
>"Georg Wrede" <Georg_member@pathlink.com> wrote in message news:buh4fj$234j$1@digitaldaemon.com...
>> In article <buempb$139g$1@digitaldaemon.com>, nobody@no.where says...
>> >
>> >http://www.stackless.com/ http://www.stackless.com/spcpaper.htm
>>
>> The spcpaper was pretty deep stuff. I ended up gawking it in awe.
>>
>> Until I remembered how I felt when I studied my first computer. (Which I learnt throug-and-throug!) The concept of having one single stack for the entire machine (bios,os,basic,user programs, all using the same stack) seemed thoroughly preposterous.
>>
>> But that was 20 years ago. Since then I've gotten so used to the stack concept that I hardly see it anymore, like the air around me. And I guess everybody here feels the same?
>>
>> Then this stackless stuff pops up, and again I'm breathless.
>> To use it, I guess, one has to unlearn 20 years' worth of
>> stacking. But the rewards may be huge for some sorts of programs.
>> I think this is like OO, recursion, coroutines, etc., where
>> it does take some time before you get a clear picture of what
>> they could/should be applied to.
>>
>> If you really can turn a language stackless without breaking existing programs, then I would't be surprised if D 2.0 suddenly turns stackless one day!
>>
>> Incidentally, I vote for not trying this before March!   :-)
>>
>>
>
>

In article <buhd3v$2h12$1@digitaldaemon.com>, nobody@no.where says...
>
>I'm just trying to inform Walter the possible options to implement coroutine/generator/continuation in D (if he doesn't know it already).
>
>Georg, as long as you keep your mind open, you will see the light :-) it's not that deep at all.
>
>Bruce, you said it has changed a lot, can you provide a pointer?  I didn't
>follow Stackless Python very closely.
>In article <buh8td$2a4h$1@digitaldaemon.com>, Bruce Dodson says...
>>
>>I'm a fan of Stackless Python too.  It has changed a lot since that paper was written, though.
>>
>>Stackless still has a stack; it's just that the Python stack is decoupled from the C stack.

The recent changes can be found at

http://www.tismer.com/research/stackless/

As I understand it, Stackless does use the C stack for its own purposes, but there is no Python stack. Instead it's more like "a bag of stack frames", of course linked together, but not into a hardwired LIFO, as a normal stack.

There are other unexpected things here too:

22-Feb-02: 1,000,000 Switches in 0.6 seconds. I was stunned when I measured switching speed on an AMD Athlon XP 1500+ machine. A python script switched tasklets 1,000,000 times. The usual Python call overhead was included. I measured this without switching and got about 0.3 seconds. That means: Context switching by an automated, internal scheduler without the interpreter overhead comes at the same cost as a Python function call.

22-Feb-02: 100,000 Tasklets in 80 MB. Right now I'm designing tasklets, which are the interface objects for coroutines, microthreads, however you name them. A tasklet wraps a chain of Python frames and a piece of the C stack -- the piece that will be needed to restart the tasklet. Today, I tested a Win32 release build and created 100,000 tasklets. The application's size grew to 80 MB. That is: A tasklet doesn't cost much more than 800 bytes.

That's about it.  When you call a function, the parts of Python that don't know it's Stackless still see that as pushing values onto a stack; so in that sense there is a stack.  But as you say it's not really a stack in the classic sense, since the stack frames can be rearranged arbitrarily.  I don't really know (or feel a need to understand) the details; I just like what it can do.

"Georg Wrede" <Georg_member@pathlink.com> wrote in message news:buhirt$2qa1$1@digitaldaemon.com...
> The recent changes can be found at
>
> http://www.tismer.com/research/stackless/
>
> As I understand it, Stackless does use the C stack for its own purposes, but there is no Python stack. Instead it's more like "a bag of stack frames", of course linked together, but not into a hardwired LIFO, as a normal stack.
>
> There are other unexpected things here too:
>
> 22-Feb-02: 1,000,000 Switches in 0.6 seconds. I was stunned when I measured switching speed on an AMD Athlon XP 1500+ machine. A python script switched tasklets 1,000,000 times. The usual Python call overhead was included. I measured this without switching and got about 0.3 seconds. That means: Context switching by an automated, internal scheduler without the interpreter overhead comes at the same cost as a Python function call.
>
> 22-Feb-02: 100,000 Tasklets in 80 MB. Right now I'm designing
> tasklets, which are the interface objects for coroutines,
> microthreads, however you name them. A tasklet wraps a chain of
> Python frames and a piece of the C stack -- the piece that will
> be needed to restart the tasklet. Today, I tested a Win32 release
> build and created 100,000 tasklets. The application's size grew
> to 80 MB. That is: A tasklet doesn't cost much more than 800 bytes.
>
>