[Stackless] Is Stackless single core by nature?

[Richard Tew]

On Sat, Jul 4, 2009 at 11:51 AM, Henning
Diedrich<hd at authentic-internet.de> wrote:
> if I could ask sth. about Stackless Python: I'm currently evaluating what
> language would fit an EVE-like game project best, server side. I know this
> is a misleading, incomplete question. There are more qualifiers but in a
> nutshell that is what I am doing and the context of my trying to understand
> Stackless Python.

Hi Henning,

I have cc'd this to the Stackless mailing list, as I prefer all my
Stackless related correspondence to be there, and this should
hopefully allow someone to call me out or correct me should I get
confused in my response.

> I think I understood some of the constraints that the EVE architecture is
> living with, namely a specific one-core-restriction. I would have favoured
> Stackless Python for benign reasons but find myself tilting towards Erlang
> now, because my impression currently is that EVE, being programmed in
> Python, could not easily be changed to using more than one core per zone.
> (Which may, of course, not be desireable in the first place for unrelated
> reasons.)

The limitation for EVE is not one core per zone.  It is that the
handling for a given zone has to run in the same Python interpreter.
And this limitation is enforced by existing code, rather than
limitations of Stackless.

During the implementation of EVE, it was thought that we would move
code down to C++ as the need arose.  And we took the simplest method
of implementing things, like zone load distribution, that could
otherwise have been done in more flexible and complex ways.  It turned
out that it was move valuable to add more content and game detail than
optimise, and the ability to buy more and better hardware facilitated
this approach.

So, handling for a given solar system tends to be delegated to a
particular node (embedded Python application running our framework).
And that node, may handle other solar systems as well.

> At the bottom of the blog
> http://softwaremaven.innerbrane.com/2007/12/python-versus-erlang-for-mmog.html
> you are commenting (quoted below) on the baselessness of the conclusions of
> the article, as I understand it.
>
> Could you give me a hint how Stackless would overcome the single-core
> issues? I have read your comments elsewhere on StacklessIO and other
> non-systemthread-blocking socket handling improvements. And I went through
> available material on StacklessIO and the EVE-architecture of maximally one
> core per solar system/zone/grid (but not vice versa).

Stackless is a microthreading solution.  It is not a scalability
solution in and of itself.  It's primary advantage is that it allows
logic to be handled with a thread-like approach without concern for
the overhead of those 'microthreads' (or as Stackless calls them
tasklets).  Stackless has a scheduler which runs on a real thread, and
all microthreads created on that thread are run within that scheduler.
 You can have multiple threads each running their own scheduler, with
their own tasklets running within them.

However, over and above this core functionality, there is the ability
to serialise running code (or 'pickle' it, as Python calls it) into
data.  You can then deserialise that data and resume its execution.
I'm not going to go into more detail about that, its been covered in
the past.  Steve Holden wrote about that on his blog at one point, you
can read it there:

http://holdenweb.blogspot.com/2006/11/stackless-python-continues-to-amaze.html

So, given you are willing to take the time to write a framework to
take care of it, this allows you to move running logic to other
'nodes', to be resumed there.  In fact, this is pretty much what
Second Life does, although they had to build this functionality
themselves given the limitations of .NET, which doesn't provide it
like Stackless does.  You can follow the link in this thread to read
more:

http://www.stackless.com/pipermail/stackless/2007-December/003225.html

And that is how I would use Stackless to overcome single-core issues.
I was writing an example framework to demonstrate this before I left
the U.S.A., but it is unlikely that I will find the time to complete
it in the near future.

> My understanding in this moment is that Python or Stackless or StacklessIO
> enforce this architecture of one-core per zone (grid). And maybe not much
> else makes sense in the first place as inter-node communication may always
> be forbiddingly slow to allow for spreading of a zone across multiple boxes.
> But at least to multiple cores? Instead of idling them?

This is all conjecture based on limited information.  The information
above should clarify why.

> Apart from the question if additional cores may perfectly satisfactorily be
> used for other, non-Python implemented calculations going on, e.g. C-number
> cruncher functions threaded out to there, and therefore need not be
> accessible for the main Python *thread* (however much partinioned into
> microthreads): does Stackless Python lend itself for multi-node
> (-core/-cpu/-blade) processing the way Erlang does?
>
> I should stress that I'd be welcoming a resounding yes and continue looking
> for it.

You tell me, given what I wrote above.

I also know little of Erlang, other than that which I have read on the
odd occasion.  As I understand it Erlang provides 'microthread' like
processes and all communication between them is message passing,
whether they are on the same node or a remote one.  It also has a
fixed syntax based around this paradigm.

One of the things I like most about Stackless is that it allows you to
write more naturally readable code.  You can take the basic
functionality and build up your own framework around this.  Tired of
callbacks?  Make a function that wraps an asynchronous operation in a
channel and whatever calls it will just read as a synchronous call.
Of course, a programmer needs to be aware of the effect of blocking
and when blocking might happen on the code they write, but in practice
this is rarely much of a concern.

To my untrained eye, Erlang is about as naturally readable as Ruby.
Well, perhaps a little bit more so.  But that's neither here nor there
:-)

Anyway, feel free to follow up with more questions, but I would prefer
you sent them to the mailing list.

Cheers,
Richard.

> My current understanding however is that it does not and cannot work, due to
> basic design decisions of Python itself that hold true for Stackless, too.
> My take away is currently that Stackless is a perfect massively
> multi-process language, which has strong benefits – but is restricted to run
> on one core. This strikes me as so unlikely as design decision but I am not
> finding information that disspells this conclusion. And technically I could
> imagine why it needs be like that.
>
> Since I saw your said comment I felt maybe I could obtain an authoritative
> answer directly from you. I hope it's perfectly clear that this is neither
> cheap criticism of the success an innovative power of EVE, nor of careful
> design decisions of Python and Stackless Pythons, nor trying to know
> anything better. To the contrary, my underlying quest is for optimal early
> design decisions to create something worthwile with rather limited means.
>
> An answer would be pretty cool, thanks in advance,
> Henning
>
> http://softwaremaven.innerbrane.com/2007/12/python-versus-erlang-for-mmog.html
>
> Richard Tew said...
> It should be noted that when EVE started using Stackless, Stackless was very
> different. At the time it used continuations and actually aimed to be
> stack-less, through eschewing the stack for the heap as you would expect.
> However, time passed and it was rewritten. As such, opinions based
> experience when EVE started using it should be taken with a grain of salt.
> Which isn't to say they are necessarily wrong, but rather baseless as a
> blind measure of the current state or utility of Stackless Python.