Python: performance, footprint, multi-threading, etc.

Alexander Staubo earlybird at mop.no
Mon May 24 20:44:10 EDT 1999


In article <37496F43.A87A362B at tdv.com>, timb at tdv.com says...
> Alexander Staubo wrote:
> 
> > As for your multithreading statement: 50-100 threads? Read up on threading! If
> > you're even considering loading this much on any scheduler, including NT, then
> > you're not up to scratch.
> 
> I just ran Process Viewer on this Windows 98 machine, which reveals that
> it's running in excess of 80 threads at the moment.  It doesn't feel
> slow.  It's not heavily loaded - I'm running an emailer, nesgroup reader
> and HTML editor.

But your machine is not a game. My system is running 240 threads right 
now. At least half of that is the core NT system (Win32 subsystem, LSA, 
core services), and they're fairly efficiently implemented: On NT, 
threads can block extremely efficiently, and things like completion ports 
help to reduce the context switch problem. I answered your question based 
on the assumption that you were writing a game, not a web browser that 
mostly sits waiting for user input.

Read up on completion ports; if you're looking for speed, there is 
currently no better way of synchronizing threads on Win32. Completion 
ports obviate the need for the scheduler to search for threads to wake, 
one of the reason loads of threads can bog down a system.

> I do know about multi-threading, thanks all the same.  You misread my
> message - or I constructed the question poorly.  I thought I made it
> quite clear that I wasn't expecting to do this at the system thread
> object level.

It was not my intention to rag on you. Perhaps I misread your question. 
However, the point remains: The only way to do what you're asking 
efficiently _is_ through kernel threads, so at some point the CPU 
juggling must be done at "system thread object level" (although I'm not 
sure what exactly you mean by that term. At kernel level?).

> > For example, if most of your threads are sleeping,
> > why are they running in the first place?
> 
> Um, because they need to be...I don't understand the question.
> 
> For example, most of the threads on this Win98 box are sleeping/inactive
> - but that doesn't mean they don't have to be maintained by the process
> scheduler.  They can't just be thrown away - something has to wake them
> up when they are needed.

Exactly.

I'm not saying hundreds of threads is necessarily the wrong way of 
tackling your problem (since I am not intimately familiar with what 
you're trying to accomplish, I'll leave that part to you). But you'll do 
yourself a favour by studying your requirements before thinking up a 
solution. Now consider _why_ you would need more than one thread. Simple: 
To maximize the potential dead time in client processing. If you have 
three worker threads and three clients, there's a pretty good chance that 
two threads will be sending or receiving data while one is actually doing 
something (ie., like computing the player's next position). Of course, 
the opposite is also true: All three worker threads could be calculating 
the player's position simultaneously. It would be appropriate at this 
point to consider what kind of processing is performed when the worker 
thread is not pushing data. Unfortunately, on a heavily used system, the 
dead time diminishes more or less exponentially as you add more clients.

Ah well. I daresay this is a complex field, and right answers on one 
platform are not necessarily correct on another.

> > And even if 90% of your threads are
> > sleeping, the context-switch hit and CPU load will bring your system to its
> > knees very quickly.
> 
> Counter-example: the game "Unreal".  It does precisely what I'm
> describing.  It seems quite fast.

I played Unreal on the Internet once. I was able to move around a little, 
although every time I tried to shoot somebody it took a few seconds 
before my gun even fired. Maybe Unreal's scripts kick ass, but its I/O 
performance is not encouraging if this is what you aspire to.

> Thanks for the other info.  I'm coming to the conclusion that Python is
> probably too complete/sophisticated for (some of) my purposes, at least
> on this project.

Too complete? Wow! :-)

Actually it does sound like you should look at LCC. I believe Quake3 is 
using LCC as the frontend compiler for its new scripting support.

> Tim
> --
> Tim Browse
> Tech Lead/Honesty Evangelist
> The Digital Village
> timb at tdv.com

You didn't by any chance take part in creating Starship Titanic, did you? 
If there ever was a game that made me want my money back, that's probably 
it (even more so than Trespasser).

Good luck with your game. I hope it will be better.

-- 
Alexander Staubo             http://www.mop.no/~alex/
"Give me an underground laboratory, half a dozen atom smashers and a beautiful 
girl in a diaphanous veil waiting to be turned into a chimpanzee, and I care 
not who writes the nation's laws." --S. J. Perelman




More information about the Python-list mailing list