Python speed?

[Jim Buck]

I've moved this over from "General Chat:It's dumb but you do it anyway":


Hey, I'm very intereted in using Python since reading "Learning Python". I will at least use it for tools, but I weakly consider the idea of using it for the game. (I *may* at least use it to prototype the game.)

Could you tell me how fast/slow Python runs on older (say from 1998) machines or if there are good articles that discuss this?



It depends on what you want to do. The standard practice is to code everything in python, then find the bottleneck (if any) and rewrite that in C.

What kind of machine are you talking about ?
Have you seen this (http://pygame.org/interview/stevemoret.shtml)?



I can't speak for machines from 1998, but as an exercise in learning Python, I'm porting my old 2d shooter, Corvids, using a simple SWIG-generated wrapper around the excellent PTK. The original game ran at around 60-70fps at a screen resolution of 320x240x8 on a 166MHz Pentium. The new version runs at a (self limited) 60fps at 640x480x32 on a 600MHz Pentium III laptop with an ancient and venerable ATI graphics card. If time permits then I'm hoping to release the Python version by the end of next weekend.

My conclusion so far. Python is great for prototyping and it isn't half bad for writing tools either. Once Corvids is out of the way, I will certainly use it to evaluate/prototype some ideas for my next game and, depending on the results, may even use it for the final product.

I know I'm in danger of turning into a Pythonista (some would say I already have) but I do like the speed at which I can turn ideas into code and I love the readability of the language. Anything that runs too slowly, I can re-do in C or C++, having done the hard work (ie, thinking) already.

If it helps, I have a bunch of Python-related links links (http://del.icio.us/rodhyde/python).

[Jim Buck]

I did see the Greyhawk game and had read the interview. That game uses Python for in-game scripting - not for the whole kit'n'kaboodle. I'm curious of the performance for games that use 100% Python. (I know about SWIG and taking certain parts and doing it in C.)

By 1998 machines, I mean machines that ma and pa were buying in 1998 and are most likely still running "Windows 98". Probably no more than 300mhz if I had to guess.

Ron, I'd be curious to check out your game when you finish it up.

I've looked around the 'net and couldn't find any documents that really get into Python's performance and ways of coding in Python that are more cpu-friendly than other ways. I do see a lot of usenet threads just generally discussing Python's speed but not many with specifics.

[Wayward]

I'm assuming we're discussing Pythons speed of execution rather than speed of development.

Python is a lovely, lovely language. Currently, I'm only using Python for tools where I find it noticeably slow at string processing, but this wouldn't be a concern for ingame scripting. The speed issues surprised me a little though, because the code isn't awful (though I make no effort to optimize) and my PC is beastly. Perhaps it has more to do with running from within my Python IDE, also written in Python.

For game scripting I use Lua which is very similar to Python. I chose Lua because it's faster, smaller, and easier to embed than Python. I do prefer to program in Python though. I have had no speed problems with Lua whatsoever.

[Bluecat]

After a lot of umming and ahhing, I'm using Python for my game(s). I am starting by writing everything except the low level DirectX code in Python.

The game I'm doing is 2D, and will initially be Windows only (though I am looking into porting to OSX and maybe Linux later.) I've wrapped the DirectDraw and Surface objects and used Boost.Python to expose them to Python (in a .pyd file.) Windows events are handled by a single window object that calls an EventHandler singleton which stores events. A single function is exposed to Python to return a dictionary object which contains all the events since the last call.

I haven't implemented sound and music yet, nor have I implemented toggling fullscreen, though the code is there to handle it. I'm getting a max frame rate of around 65, and an average of 62ish. This is good enough for what I want to do, the sort of games that I am doing will not require massive framerates.

I reckon I should be getting a higher framerate, but somewhere I remember reading that Python tends to be limited here (by what I'm not sure.) Version 2.4 is soon to be released and one of the things they are talking about is improving the performance of some parts of the system by about 30 percent. It's also possible that going to fullscreen will also improve performance, IIRC windowed modes tend to be slower, though it's been a while since I've checked this.

If I find that (as I progress) my performance starts to drop below an acceptable frame rate, I will simple move more of the system into the .pyd. I've already got a few ideas of how to do this.

[Jim Buck]

@Wayward:

Yeah, I'm talking about speed of execution. How "beastly" is your pc that you are running your Python tools on?

@Bluecat:

Where did you read about Python being limited in its frame rate? How complex is your 2d game?

[Bluecat]

It wasn't so much that it was limited in its frame rate. There were some timing issues that I read about. It's very vague I know, and I can't remember where I saw the info. Doh!

It's just that the extremely vague recollection of an article that I read ties in with the observations that I currently have.

[Rod Hyde]

Rod, I'd be curious to check out your game when you finish it up.Jim

No problem. It really is just a proof of concept / learning exercise, so I'd be more than happy to make it available.

--- Rod

[mathgenius]

I reckon I should be getting a higher framerate, but somewhere I remember reading that Python tends to be limited here (by what I'm not sure.) Version 2.4 is soon to be released and one of the things they are talking about is improving the performance of some parts of the system by about 30 percent.

Ahh, and python2.3 was meant to be 30% faster than 2.2, which I am using for stability reasons.

My game editor gets 80+fps, on a 2GHz Athlon; I don't think there is inherant limitations to the framerate. The only thing I can think of is that python uses a global interpreter lock (the dreaded GIL), which means bytecode in other threads (eg. callbacks from external libraries) may have to wait for this lock to be released (which happens every few bytecodes).

Simon.

[Larry Hastings]

I'm planning to use Python for my next game. I discussed it a little over email with Simon, and his early results bode really well for my project. I plan on leaving the low-level inner-loop stuff (collision detection, pathfinding, all my existing support libraries) in C++, and making 'em available in Python, then write the game logic in Python.

I rather suppose it depends on your target machine. My current game was targeted to a 500MHz CPU and 16MB graphics card, and at this point in development I find I have CPU cycles to spare and then some. So I could have used the scripting language for more, and used a slower language to boot, and still have made my specs with ease. (I doubt you'd want to run my game on an 8MB card, though in all honesty I haven't tried it. And since there probably aren't a lot of slow CPUs with 16MB cards, I figure there's no point in trying to reduce the CPU specs any.)

Re: locking the GIL: Do you have that problem with your game too, or is it just the editor? I use "The Big Game Loop" in my game, and figured I'd use it for my next game too. If you only have one thread ever in the Python interpreter, I trust the GIL won't bug you.

[mathgenius]

The game uses python's OpenGL/SDL libraries; I've just found that the editor runs at over 200fps on my Athlon.

In the past I have wrestled with the GIL; I was just trying to figure out what bluecat has been refering too. And yes, if there is only one thread calling python code, then there is no problem with the GIL. I use portaudio for sound (v18), and it needs to callback into python code from it's own thread. yada yada.

Simon.

[Jim Buck]

Today, I was reading a bit on speeding up Python code (http://www.python.org/doc/faq/programming.html#id6) and came across a couple (http://manatee.mojam.com/~skip/python/fastpython.html) of articles (http://www.python.org/doc/essays/list2str.html) (both a bit dated I think) that dealt with performance and more optimal ways of doing things in Python. They were rather short, though, but still an excellent read. I hope to find more such articles.

I think I will still at least prototype the game in Python and see how it runs on older systems before making a judgement about whether to be 100% pure Python or not. It's hard to say unless someone here does run it on much older systems.