Re: [pygame] Python and Speed

["René Dudfield" <renesd@xxxxxxxxx>]

On Thu, Apr 17, 2008 at 12: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 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.
>

Here's some ways to make CPython faster:
1. - better machine specific compilation.  distutils mods to compile
extensions with machine specific optimizations.  eg.  _array_athlon.so
_array_pentium.so (1.2 - 4x speedup).  At the moment most python
distributions use the lowest common denominator instructions - eg
i386.
2. - asm optimizations.  eg. optimized memcpy routines are at least 5x
faster than one included in
glibc(http://www.freevec.org/function/memcpy).  There seems to be
almost no asm optimizations in CPython.
3. - faster threading.  It's easy to get 2-8x speed up on desktop
machines with 2-8 cores.  CPython could use faster threading
primitives, and more selective releasing of the GIL.  Pygame has used
fine grained selected locking fairly successfully - so I think it
could be done for the rest of python too.  The next step for pygame is
to make these threading enhancements able to be used automatically -
through sprite mixins.
4. - Improving the array type in python itself would also go a long
way to speeding it up for many.
5. - regression tests for speed.  So the speed of things can be
measured and tested more easily.
6. - memory optimizations.  eg, the kjDict can use a lot less memory
than the built in dicts.  A way to know how much memory is being used.
 Memory profiling is the most important way to optimize since memory
is quite slow compared to the speed of the cpu.



I think there is work in each of these areas - except 1, 2,4.

I think #1 is the easiest way to speed CPython up dramatically with
the least amount of work.

For #2 (optional asm optimizations), there is a lot of code CPython
could use today - including the freevec library I linked to as well as
libraries released by intel, and amd.  I think that perhaps releasing
a patch with a few selected asm optimizations might let the python
developers realise how much faster python could be... but that's a
fair amount of extra work.

#6. Things like the cgkit slot attributes can save a lot of memory -
eg, a slot int attribute takes up 4-8 bytes, whereas a python int
attribute takes up (guessing) 200 bytes.  I think the python slots
already help with memory use... but I haven't measured it.



cheers,