Tasklets aren't threads in the conventional sense. They're just a convenient method of maintaining an execution state. The *purpose* of tasklets in game AI is nothing like that of real OS threads, which of course would be absurdly inefficient.
Now that I go back and re-read that OGRE forum thread from two years ago, I believe my intention was to demonstrate that "context switching" between tasklets was somewhat expensive. Certainly more so than iterating through all your game objects and calling an AI routine would be.
Again, anyone's welcome to craft a more realistic benchmark based on different approaches to game/simulation AI. In Python, comparing Stackless tasklets to standard generators might be interesting.
Game state: serializing cooperative threads?
See I would think the tasklets would shine in the case of objects that don't need updates all the time. If the scheduler is even remotely smart, it could store a list of tasklets sorted by "time to wake up". (this would be wakes up at 1:23:41.023 instead of storing wakes up in 6.023 seconds)
Then all of a sudden all the random AI crap of something like eve (wich has TONNES of things that cycle in the 4-10sec range) becomes a much smaller compute problem because you aren't iterating over anything but the (hopefully) few items that need updates at this time.
I agree that tasklets have overhead much more so than just calling functions. But hopefully the wait-on-event semantics of a tasklet allow you to save a lot of compute time. (now you could roll your own signals/slots setup and manually set up a possibly faster event system, but from what I remember about stackless you can code normally and any function that is a tasklet interface automagically incorporates waits on event)
Then all of a sudden all the random AI crap of something like eve (wich has TONNES of things that cycle in the 4-10sec range) becomes a much smaller compute problem because you aren't iterating over anything but the (hopefully) few items that need updates at this time.
I agree that tasklets have overhead much more so than just calling functions. But hopefully the wait-on-event semantics of a tasklet allow you to save a lot of compute time. (now you could roll your own signals/slots setup and manually set up a possibly faster event system, but from what I remember about stackless you can code normally and any function that is a tasklet interface automagically incorporates waits on event)
A belated update, now that I've had time to test some ideas:
Generators in standard CPython are, most unfortunately, not pickle-able and therefore are probably unsuitable for microthread-like AI in games, because saving/loading would be nontrivial.
Anyway, I'm starting serious work on a game that will have a couple hundred agents to begin with, and I'm going to try to create multiple AI interfaces using Stackless Python 2.6: maybe one with tasklets, one with generators (which Stackless *can* pickle), and a more typical one that would be fully compatible with CPython. Hopefully I'll have some interesting results in the nearish future.
I was somewhat discouraged by this thoroughly unimaginative example, which sends every tasklet a "WORLD_STATE" tick and handles logic just as you'd expect. I'll try to do something more like Robocode.
Generators in standard CPython are, most unfortunately, not pickle-able and therefore are probably unsuitable for microthread-like AI in games, because saving/loading would be nontrivial.
Anyway, I'm starting serious work on a game that will have a couple hundred agents to begin with, and I'm going to try to create multiple AI interfaces using Stackless Python 2.6: maybe one with tasklets, one with generators (which Stackless *can* pickle), and a more typical one that would be fully compatible with CPython. Hopefully I'll have some interesting results in the nearish future.
I was somewhat discouraged by this thoroughly unimaginative example, which sends every tasklet a "WORLD_STATE" tick and handles logic just as you'd expect. I'll try to do something more like Robocode.
drakostar, I'm also looking into Stackless for agent cooperative threading. Have you any ideas on how to effectively take arbitrary files of Python code and attach them to individual agent instances? Examples like the Olsen link you posted assume you're writing everything in Python and that the agent script code is part of the same program as the Stackless system you use to manage them. I'd quite like to have a C++ host app which sets up the Stackless scheduler, and then loads in Python scripts, associating channels with them etc.
Quote:Original post by KulSeranQuote:
The only real drawback, as far as I'm concerned, is performance. If you have some kind of simulation with thousands of agents, creating a microthread for each one is not a practical approach. But if you're only dealing with hundreds at a time, it's not an issue.
Tell that to eve online. They use it because it is the most performance friendly way for them to manage all the thousands of agents in their game.
Using EVE as a benchmark for how efficient Stackless is, is a terrible idea. Having been a long time EVE player, I can tell that EVE basically chokes when more than 200-300 players are in a system, attempting to fight. I've literally been in fights where the client to server lag was measured in hours, because the servers would choke because of all the Stackless microthreads they spawned.
They recently changed their IO system however, so that problem may have alleviated somewhat.
I'm still hoping for a response from drakostar though. :) Turning arbitrary strings of Python into functions that can be run on a per-instance basis seems a bit tricky in Python (and trivial in Lua, irritatingly).
I'm still hoping for a response from drakostar though. :) Turning arbitrary strings of Python into functions that can be run on a per-instance basis seems a bit tricky in Python (and trivial in Lua, irritatingly).
Quote:Original post by Kylotan
They recently changed their IO system however, so that problem may have alleviated somewhat.
I'm still hoping for a response from drakostar though. :) Turning arbitrary strings of Python into functions that can be run on a per-instance basis seems a bit tricky in Python (and trivial in Lua, irritatingly).
Yah, it simply moved the lag around. Instead of 45 minute load times, you get more consistent 3-5 minute load times, which, I guess is better overall, but it really just moved the problem around, it didn't alleviate it.
To be fair, EVE has much deeper problems than just Stackless Python. For instance, their network I/O is based entirely on TCP, and they send huge 8 meg mega-packets that are just stupid. If even a byte of that mega-packet gets lost, the whole thing is sent again. So you have to take the whole system in to account, but Stackless Python IS an issue in that environment.
Now, for a single player game, where you're not going to be managing 500 players, plus 5000 AI drones/fighters, in a single system, it's probably fine.
Quote:Original post by drakostar
Woops, it was a different forum. Here is my test code.
Just ran your test on stackless 2.5 I get 17.1 for stackless and 14.4 for iterative
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
