[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] Python and Speed
On Apr 16, 2008, at 6:36 PM, Ian Mallett wrote:
Recently, I've been having issues in all fortes of my programming
experience where Python is no longer fast enough to fill the need
adaquately. I really love Python and its syntax (or lack of), and
all the nice modules (such as PyGame) made for it. Are there any
plans to improve Python's speed to at least the level of C
languages? I feel like Python is living down to its namesake's
pace...
Ian
Python is slow, it is an interpreted language geared toward rapid
application development at the expense of execution speed. It is also
designed to be highly portable, also at the potential expense of
execution speed.
That said, much effort is put into making python perform well, and it
is certainly possible to make extremely fast python programs when an
algorithm is available that allows you to make clever use of data
structures to get the job done more efficiency. And optimization is as
much about data structures as it is about code (maybe more). Python
comes with some tools (cProfile in particular) that allows you to
figure out where your code is spending its time so you can speed it
up. Note that by removing inefficient code, or choosing a better
algorithm, it is possible to get massive speedups in Python and any
language.
Sometimes (especially in things like graphics and simulations) there
is no magic algorithm to make things more efficient. Many times the
best you can do is O(N), O(N^2) or even O(2^N). In these cases, Python
runs out of steam real fast (in fact any language runs out of steam
fast with O(2^N) algorithms). This is especially pronounced in games
where you have to perform operations over large arrays once per frame.
This is typical in 3D graphics, physics and particle systems. What you
must often do in such cases is move the inner loop of these operations
into native code.
The easiest way to do this is to find a native library that already
performs the operations you need. This could be a generic library
(like numpy) or something more specific (like pygame or ode). This is
especially easy if the library already has a Python binding, if not
you can make one using ctypes, pyrex or C directly. The downside here
is the additional dependancies.
If nothing exists that does what you want, you'll need to write some
native code yourself. First identify the slow code. Make sure there is
no way to make it fast enough within Python (is there a better
algorithm? etc). Then move this code into an extension, written
however you prefer. Note it is fairly easy to create an extension
module that defines some functions in C that can be imported into
Python (especially if they just do number crunching), the most complex
aspect is the memory management. Tools like pyrex can automate that
for you, but don't give you as close control over the code.
But before you do any of this, do some profiling (run your game under
'python -m cProfile') and see what's taking up the time. How much time
per frame do you have for game logic? Is your logic too slow or is the
drawing too slow? Honestly, my biggest problem with pygame is not
python being too slow, but the fill rate of SDL being too slow. I can
solve the former with optimization and extensions, but the latter
requires much more compromise (lower res, smaller sprites, etc). The
hard reality is that the CPU is often too slow for graphics work no
matter what language you use (even highly tuned SIMD asm code). That's
why we have dedicated graphics hardware designed for the task. Right
now SDL doesn't really take advantage of that, and that's a big
limitation.
-Casey