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

Re: [pygame] C/C++ and Python



On Mon, Apr 20, 2009 at 9:28 AM, René Dudfield <renesd@xxxxxxxxx> wrote:
> hi,
>
> The main reasons not to use opengl, and instead use pygame graphics are:
>     - opengl is not as portable.
>     - it's harder to write opengl code that'll work everywhere because of
> bugs in various opengl drivers, cards and python bindings.
>     - it's more complex to write opengl code.
>
> So if you're just wanting to write a game, I'd avoid opengl.  If you want to
> play around with graphics, then definitely give opengl a go.  It'll be
> educational too.
>
>
>
>
>
> To answer your original question...
>
> Some times you need the extra speed, and then writing C can be a good way to
> go.  Or if you need to wrap an existing C library, so you can use it from
> python.
>
> pygame tries to keep the minimal amount of things needed done in C/asm so
> you don't need to write so much C yourself for games.  If there's some code
> that is useful for lots of games, it might be a good idea to contribute it
> to pygame, to keep all the C in one place.  So you get the benefit of fast
> C/asm code, callable from python.
>
> Using C, asm, and python appropriately you get the best of all worlds.  Make
> the 0%-5% of your code that really needs it be C/asm... if it needs it.
>
>
> Combined with things lke psyco, and numpy - you can avoid doing a lot of
> things in C.
>
> The hope is that eventually python itself will come close to C speed, so
> you'll need less C... However that hope has been with me for over 10 years,
> and I see no real progress speeding python itself up.  Where as C in the
> meantime has gotten a lot faster.  C compilers available now can do
> autovectorization, profile guided optimisations, and all sorts of magic,
> that python is a long way from.  There's even compilers that help with auto
> SMPing, and auto MIMDing your code.  I see no reason why this will not
> continue to be the case.  C has a lot more smarter people working on it
> compared to python, so will always be a lot faster until that changes(which
> will not happen in our lifetimes).
>
> However, there is a lot more knowledge in the python community now about
> jit, and asm stuff than previously... so it'll be interesting to see where
> we are at with that in 1-5 years.
>
> Having said that, things like pycuda, and pygpu begin to close the gap.
> Since they offload a lot of the work to the GPU - which work in an array
> like manner.  The native language for GPUs is increasingly looking like C -
> with vector SIMD, and MIMD extensions.  Most C compilers for CPUs also have
> vector extensions these days too.

Have you seen this?
http://arstechnica.com/open-source/news/2009/03/google-launches-project-to-boost-python-performance-by-5x.ars

Also this makes the python speed point very well. One last thing I
would add is that code speed is often not needed anymore. I have never
in the last 10 years had to worry about code speed while writing a
simple 2d game like pong, tetrus, defender, donky kong or anything
else like that.

http://www.scipy.org/PerformancePython


-- 
Douglas E Knapp

Why do we live?