Multithreaded Game Scripting with Stackless Python

All sorts of discussions about the DragonScript language.
Post Reply
User avatar
Khan
Intermediate
Posts: 69
Joined: Fri Sep 17, 2004 9:31 am
Location: src/packages/collections/

Multithreaded Game Scripting with Stackless Python

Post by Khan » Sun Sep 18, 2005 5:56 pm

I don't know where to put this, so I put I here:
http://harkal.sylphis3d.com/2005/08/10/ ... ss-python/
good read, and a lot too (I'm not yet finished)
....................................................................
Time: 0.090000 seconds

OK
(68 tests)

User avatar
Dragonlord
Forum Administrator
Posts: 609
Joined: Fri Jul 30, 2004 4:30 pm
Location: Switzerland
Contact:

Post by Dragonlord » Sun Sep 18, 2005 8:43 pm

nice stuff and some good ideas, with only one catch, but the catch is the same with all multi-thread applications not only games, and that's synchronization. i'm sure he dealt with it in a certain way though. the main problem of having lots of thread for each task running is that you need to synchronize them together. it is one thing to have an ongoing process and then you need to interact with the world suddenly. major problem is that in such a situation you need to know about the way the engine handles certain 'things' as otherwise you read 'wrong' states if you tap in at any possible time.

that's why i am for the object oriented approach instead of mutlithreading, which is in my opinion the bigger lagacy thinking than having an update-function (which i use, but is not mandatory). all those concurrent operations are done using 'events'. you do not run all the time and poll for a situation to arrive (which you would do if you have multiple threads for the sake of it) but you wait until something happens. this way you do not use CPU time at all. of course if you have a situation of something running all the time a thread is usefull.

my experience with threads has been so far that altough running them concurrent is fast the synchronization work needed to avoid data corruptness or even race-conditions can quickly kill the previously gained speed. a bench of the two technics would be nice to see though ^_^
Image
Oh to be a dragon, of silkworm size or immense...

User avatar
Khan
Intermediate
Posts: 69
Joined: Fri Sep 17, 2004 9:31 am
Location: src/packages/collections/

Post by Khan » Sun Sep 18, 2005 9:44 pm

Dragonlord wrote:nice stuff and some good ideas, with only one catch, but the catch is the same with all multi-thread applications not only games, and that's synchronization.
Yeah, they mention it as a tradional problem and you somehow expect that they found a nice way to solve it (callbacks, whatever) but then in some hidden sentence they confess that they didn't solve it.

What I found very interesting was their explenation why they don't need preemptive threads. It would be very interesting if the stackles-python-vm is multithreaded so that you can take advantage of several CPUs or cores but I doubt it is.

And I certainly don't like their VB style for events and actions. Also why the fuck CDoor? Python has packages (called module IIRC), so use them!
Dragonlord wrote: my experience with threads has been so far that altough running them concurrent is fast the synchronization work needed to avoid data corruptness or even race-conditions can quickly kill the previously gained speed.
Because of all this, I don't really expect much from `Dual-Core-Games' except bugs. Makes you wonder what Micro$~1 and SoNie where smoking when designing XBox-360 and PS3.
....................................................................
Time: 0.090000 seconds

OK
(68 tests)

User avatar
Dragonlord
Forum Administrator
Posts: 609
Joined: Fri Jul 30, 2004 4:30 pm
Location: Switzerland
Contact:

Post by Dragonlord » Mon Sep 19, 2005 12:31 am

in fact the idea of using multiple threads for games works out in certain situations, but those are already in use: GPU, SPU and CPU. with other words if you have tasks which are really independant like playing a sound sample or rendering stuff to a buffer you can launch and then detach. requires though either a simple blocking call which for example delays rendering a scene until the former has finished (which runs while you prepare the next) or you copy all to a temporary buffer you work with hence beeing autonomous.

those kinds of threads really help but as soon as you need feedback from a thread you are jammed with synchronisation. multiple CPU cores don't help the cause a lot but multiple units like SPU or GPU do help. that is also why i am very sceptical towards this PPU (Physics Processing Unit) which shall handle physics in games and is YAPC (yet another pci card) in your pc. this needs unfortunatly feedback (called collision resolving in game physics terminology) and this is done very often during one frame update (often around 50 steps per frame update with multiple collisions during each step). don't ask me how you want to handle this with a narrow bus like a pci or even pci-express. but that's called marketing, not boys? ;)
Image
Oh to be a dragon, of silkworm size or immense...

Post Reply