[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] Python and Speed
- To: pygame-users@xxxxxxxx
- Subject: Re: [pygame] Python and Speed
- From: "René Dudfield" <renesd@xxxxxxxxx>
- Date: Thu, 17 Apr 2008 12:47:57 +1000
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: pygame-users-outgoing@xxxxxxxx
- Delivered-to: pygame-users@xxxxxxxx
- Delivery-date: Wed, 16 Apr 2008 22:48:19 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=uBklZ/nlotNNWbv+kqU+/c+YCQV0YFVjG1WlpGHS9oI=; b=pXoYSkA109EDTwAN0oFXc4zEue5JoT4tB0qt5RA6KqaRNPeCZmushFWD7w4ofkQCB5a5UgFfgPnBHUxfV5FEbRWpAZJ1cDmZQPeTgunckqiIvoSwUfLI2wAr+N3xuayZq21M9DYAT3CJObTKMWoojb2NFePesEKfFaOAfIcqshA=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Mq70OOpi2KRfDcWoYN2zCfNKxVAQDYmKoggkSTel+6iiICEyx8MgGk0qEHVzrq4CBcsmbsF+JSqtavglZJWTVAv6xQ5kzUrK/Mm4IGxHsq+dA8Uop3SrErqh/I+l+3MNC0xLdYoKpn9kefvVvnwzNWs637Chzra3OUG4DcTjOs0=
- In-reply-to: <200804170204.m3H24I8e029286@xxxxxxxxxxxxxxxxxxxxxxxxxx>
- References: <200804170204.m3H24I8e029286@xxxxxxxxxxxxxxxxxxxxxxxxxx>
- Reply-to: pygame-users@xxxxxxxx
- Sender: owner-pygame-users@xxxxxxxx
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,