Python in game development?

[Mallor]

"Courageous" <jkraska1 at san.rr.com> wrote in message
news:39765839.ADB85077 at san.rr.com...
>
> > > http://www.stackless.com/
> >
> > What exactly *are* these advantages? (Very curious...)
>
> Stacklessness allows certain specific optimizations for
> threading that wouldn't be possible otherwise. For example,
> it's quite possible to run 10,000 threads simultaneously
> in stackless Python, which is especially useful if you have
> lots of small simulation entities which are doing various
> and sundry routine and small tasks.

If I had 10,000 of anything to process, why wouldn't I try to batch that
up?  Only answer I can think of is if you had 10,000 fairly unique
things going on.  Like 10,000 players on a MUD server and nobody shares
any turn-phase actions at all.  I'm not sure that's how I'd design a MUD
to begin with, sounds pretty bloated.  I don't think I'd need 10,000
asynchronous Active Server Page transactions for an e-commerce website,
I think I could queue 'em.

So, 10,000 sounds like a pretty theoretical advantage.  I'd be more
interested if there's some big payoff for, say, a dozen heterogeneous
processes?

> One of the things that stacklessness enables is the "first
> class continuation" which is really a generalized primitive
> for doing flow control. If Python came coupled with any
> kind of metalinguistic/macro environment, it would be possible
> to any number of flow control and looping constructs,
> practically without limit.

I guess my suspicion about primitives for doing flow control, is I've
spent most of my computer career learning how to pipeline the flow
control tighter and tighter by regularizing the units of computation.
Sure, some problems aren't amenable to that, but most problems are, and
I'm not sure I want to pay maintenance overhead to have the conceptual
elegance.  After all, main memory access in a flat address space is
pretty elegant until you have to deal with a cache hierarchy.

> "first class" continuations expose the various pieces
> of functionality in 1-4 to the ordinary programmer. It
> is no longer a matter strictly controlled by the
> interpreter/compiler. The programmer can then make
> meta-level decisions that would have otherwise not been
> doable without the continuation construct.

Fair 'nuff, I'd use it to blow off all returns.  Once the packets have
been shipped to some hardware interface - 3d, network, whatever - what
do I care about gratuitously returning from subroutines?  The pedantic
answer is exception handling.  Well, screw exception handling!  :-)

Of course, the design level method for coping with this problem is using
big arrays of stuff that you can repetitively chug through, to minimize
or even eliminate function call overheads.

> The idea of "stacklessness" per se is doing away with
> the push/pop operations altogether in order to facilitate
> the continuation itself. Without having to constantly
> push/pop stack elements, context switching between threads
> or regions of memory becomes very cheap.

Only if the consumption of resources by the threads themselves is cheap.
If they're all a bunch of memory hogs, you've just invented a great way
to thrash.

> There's a cost involved here, but if you're doing lots
> of context switching, you very often don't care.

I hate context switching.  All efficiency comes from hardwiring the
context.

> This kind of environment is particularly of interest to high
> performance computiationalists who use massively parallel
> machines.

And of no interest whatsoever to those of us using serial machines on
mainstream PC industry CPUs.  But your point is taken.

--
Cheers,             Infernal Troublemaker                    Troll
Mallor              "By simple mistake, mortals themselves amuse."