ANN: Stackless Python 0.2

[Gary D. Duzan]

In Message <37791B4D.43ADC401 at appliedbiometrics.com> ,
   Christian Tismer <tismer at appliedbiometrics.com> wrote:

=>Gary Duzan wrote:
=>> 
=>> Toby J Sargeant wrote:
=>> >
=>...
=>>    This appears to be the conventional wisdom. The optimization class I
=>> took used an ML-like language, and the first thing we did was to move
=>> heap frames, which was the default, to the stack (i.e. closure
=>> optimization.)
=>
=>Loosing much of flexibility by doing that, btw.

   True. For example, (if I remember correctly; it has been a while)
tail call optimization is defeated. In this particular case, however,
we didn't break the language semantics (which didn't guarantee constant
memory tail recursion) because we only did stack conversion after
checking that it wouldn't break anything. Otherwise, the closure is
left on the heap. I see that I wasn't clear about that in my original
post; sorry 'bout that.

=>> It might be less of an issue in an interpreted language if it already has
=>> heap
=>> allocation (or other sorts of) overhead to deal with when making calls.
=>> There may be other allocation tricks which can be used, as well.


=>> > It seems that this should affect Stackless Python equally as much. Does a
nyone
=>> > have anything to add on the subject? I would imagine that frames could be
=>> > allocated and managed in chunks to alleviate a lot of the memory manageme
nt
=>> > load...
=>> 
=>>    I would think that as well (at least at first.) Maybe pools of different
=>> sizes of frame to limit the space overhead.
=>
=>Maybe you should really look into the sources.
=>You are discussing things which are not Python
=>related, since this simply does not apply.

   Freely conceeded.

=>The Python "stacks" are so tiny that you can forget about them.
=>Allocations always never occour, unless your program runs
=>astray in recursion.
=>
=>The cost of a call comes from the slightly complicated
=>function setup which is done all the time. Frames belong
=>to the fastest available Python objects already, 
=>like, say dictionaries.

   I thought that might be the case, which is the point I was making in
my earlier paragraph. I was just briefly pondering possibilities for
reducing frame memory management time, if it were necessary. Stackless
Python certainly seems to me to be a Good Thing.

					Gary Duzan
					GTE Laboratories