RE: Re: stackless implementation (was Re: New stacklessproposal)

> From: Christian Tismer

> >>>If "stack pooled" can do everything and is fasted and smallest why
> >>>offer anything else?  Is there no disadvantage at all?
> 
> Aaah! Sorry,  I did a wrong classification. Copy & paste...
> 
> "Stack pooled" is of course not low memory.
> 
> > What is the "cost" of extra stacks?  Is it memory or speed? 
>  As long 
> > as it is less memory than OS and faster than OS then it is 
> justified.
> 
> No, it is much memory, as much as a minimum C stack.
> I think 64 k would fit.
> 
> ...
> 
> > If it is slower that the pure interpreter on some platforms but 
> > supports C extensions, I may still decide to go with only that 
> > solution.  Having a combination solution where one choice doesn't 
> > support C extensions is very non-orthogonal and messy, 
> especially if 
> > it is only for the benefit of a small part of the user base.
> 
> No no, the pool thing is for speed only, and only if it 
> really pays off.
> 
> ...
> 
> > If there is C stuff on the stacks, then don't they have to be 
> > arbitrarily big because we cannot predict how big they need 
> to be?  Or 
> > do you still have one big OS stack that they initialize on and then 
> > you copy only what the C function uses over to the multiple stacks?
> 
> No, the latter is what I do now.
> Sorry for being so unspecific.
> The pool thing is just if you want to squeeze
> the last snot of speed out of your interpreter.

Oh, normal marketing, all lies.  :-)

Oh well, I should have known it was too good to be true.  I'll hold off
on the pooled stacks unless/until you come back with some amazing
performance.  Your are competing with the OS with this new feature.

Right now I think the tasklets with C stack copying for one type of
thread combined with OS threads is a good overall conservative
combination.  If I understand you correctly I can implement this with
your basic assembler primitives and by asking lots of questions. :-)

I'll clean up my proposal to reflect this and then we'll revisit it.