[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Python and Speed



On Wed, Apr 16, 2008 at 7:04 PM, Richard Jones <richardjones@xxxxxxxxxxxxxxxx> wrote:
Ian Mallett <geometrian@xxxxxxxxx> wrote:
>  Are there any plans to improve Python's speed to
> at least the level of C languages?

This isn't really the best forum for asking such a question. I would recommend asking on the general Python mailing list / newsgroup ("comp.lang.python" on http://www.python.org/community/lists/).
I know, but this list is so responsive, and the problem can actually be related to pygame--although somewhat remotely.  Python is slower than C and so will be used less.  Pygame depends on Python's success.  We should be concerned about the future of Python because it determines our future as well.  OK, so I posted to the wrong list...
I think I speak for all Python developers when I say that we'd love for the language to run faster. And of course the large body of core CPython developers are aware of this. I've personally attended a sprint in Iceland during which we spent a week solely focused on speeding up the CPython interpreter.

There's just not much that can be done with the current CPython implementation to make it faster.
Why not?  If C is faster, why can't Python be equally so?  If we assume that C is the fastest a language available, then that implies that Python could be faster should it adopt the same procedures as C. 

I've gathered that Python is based on C code, so it translates your code into C code on the fly.  I have not idea whether this is veritable...  Obviously, this results in slow-downs.  Do what C does, don't try to copy it...
Thus it falls to you as a developer to choose your implementation strategy wisely:
But again, this is treating the symptoms, not the problem...
1. pick sensible libraries that handle large amounts of processing for you (whether that be numeric or graphic)
I assume these libraries are written in C, correct?  What if it didn't matter and they culd be written in Python or C with no noticeable speed loss or gain?  that would be great!
2. where there is no existing library, you may need to code speed-critical parts of your application using C, or the more programmer-friendly Pyrex (er, Cython these days I believe :)
This last I am interested in.  Obviously, I can't really do much for Python's speed, so I do need to consider my implementations.   How can you run a C file from a Python script?  This would speed some of my projects up enormously...
On Wed, Apr 16, 2008 at 7:04 PM, René Dudfield <renesd@xxxxxxxxx> wrote:
hi,
Hi
Each release of python gets a little faster... but not massively.  It
really needs to get 10-20x faster - but generally only gets up to 1.2x
faster with each release.
Why is this?  If Python is based on C, is C getting faster by only 1.2x each release?
There's also work on things like pypy - which might one day be quite
fast.  I think pypy will drive Cpython to get faster through
competition - and ideas.  An example of this recently happening is the
method cache (which I think the idea actually came from tinypy...).
The method cache was shown to work well with pypy, and then Cpython
added the idea.  If pypy becomes faster, then I think the Cpython
people will try harder to make Cpython faster too.
I would like to get to the point where Python and C are competing speed-wise.
However mainly it's good to try and make highly reusable, and fast
basic building blocks - and then glue them together with python.
in C?
For example, if you see something that most pygame games would get
faster with, then add it to pygame.  Or to SDL, or to python.  If the
drawing part of the game takes 10% less time, that leaves 10% of time
for game code.  As examples in the last pygame release - The
pygame.sprite.LayeredDirty sprite work, the threading work, and
modifications to some functions to allow reusing surfaces(eg
transform.scale) in the last pygame should make a lot of pygame games
quicker.  For SDL the blitters have been optimized with mmx, and
altivec assembly - and the upcoming SDL 1.3 can optionally use opengl,
and direct3d hardware acceleration.

Also the included PixelArray should allow you to do a lot of things
quicker - and you can rely on it to be included with pygame(unlike
numeric/numpy).  We hope to have fast vector, and matrix types
included at some point in the future too.

If you've got any ideas for reusable speed ups - we'll gladly consider
them in pygame.
The things I included in my Pygame Advance Graphics Library I think are good candidates.  I use the particle systems all the time, for instance.  These are just shortcuts--they really aren't speed-improvements, except in the game development field, where they would help people rapidly prototype a game concept.  Ideally, I would like to see my library become obsolete by adding similar stuff to PyGame.  But:

At a certain point, too, PyGame would provide too much--for example, though faster, pygame.draw.dotted_line() would be used so infrequently as to clutter the documentation and library in general.  The correct method would be to leave these functions out of PyGame, and just let other people, like me, come up with extensions--which would provide the function at a balance between speed and clarity. 

Again, all this is just treating the symptoms.  Python is slow, and while optimizations can only be made, it's like fixing a broken submarine with duct tape.  Solution, get a new sub. 
cheers,
Ian