Re: [pygame] Python, Pygame and Performance

[Jacob Schwartz <kevlarx@netidea.com>]

Pete Shinners wrote:

> First off I want to point out that Python is far more than a "glue" 
> language. While very good at that task, it does even better at a full 
> programming language.
True. I did not intend to pin Python as just a glue language, but more 
emphasize its strengths as one. - A damn fine one :)

In my (somewhat limited) experience at building games I have noticed 
that the ability of a language to tie various languages together (be it 
using assembler in the tight loops, C for the high level - or using C 
for the tight loops, and Python for the high level) far outweighs any 
other feature.
Yet this is seldom noticed in the 'main stream'.

Using a very high level language also gives someone like me (I tend to 
work alone .. unfortunately) the ability to implement fairly complex 
algorithms as I won't drown in the details.
This gives a much more significant performance gain then writing 'tight 
loops' and squeezing a few cycles off a simple minded algorithm would.

> I remember when Wolf3D was nearing release and everyone was rather 
> impressed that the game was written in about 90% C. Such a "high 
> level" language to be doing all those fancy graphics.
I am wondering when the act of profiling ones code to see where the 
bottle necks are will finally overtake the tend to optimize it all, 
'just in case'. (Even though its long been common knowledge.)
In a worst case scenario, I could write a module in Python and discover 
it is too slow for my needs then re-write it in C/C++ (which is almost 
just a simple switch of syntax + some extra code).
There are a few somewhat recent games written in all assembler, such as 
Roller coaster tycoon (1999). They're marvels of technology (IMHO), but 
really - most people scoff at the effort spent on it...
So when will people begin to scoff at games written entirely in C/C++?

> Probably the biggest argument for high level languages is the Unreal 
> engine. This is a bigger step up from Quake's compiled C bytecode. 
I used to write a heck of a lot of QuakeC, and that language was far 
from optimized and had lots of limitations (if I remember correctly, the 
code was only 'ticked' every 10th of a second anyway, and all the floats 
had shoddy precision). But again, I loved it. More rapid development and 
'comfy syntax'. -- Yet it had mass appeal.

I scratched my head for a long time, trying to figure out why it was 
used, and not DLLs (after all, it looked almost exactly like C)- and 
sure enough, the next version of Quake used DLLs :)
In my opinion a big step backwards. A more logical way to go would have 
been toward something more Lua or Python-esc.

> ... My point here is, use Python to write games if it works for you. 
> Don't think it necessarily makes you more productive or better than 
> anyone else.
Makes sense. But its more difficult to come to understand that then it 
seems.
Bigger better tools should make bigger better workers. At least thats 
what is beaten into our heads.

> In my personal case, Python takes a programmer who could never get a 
> complete game finished with C into someone who enjoys creating, 
> fixing, and working on game programming. Performance has not been a 
> problem.
A good point - but your case may not be typical.
My guess is that the most successful python programmers are ones who can 
take on a game in any language. Sure it might help someone finish a 
project that they might otherwise drop - but more likely someone can 
pick it up, and take on (and complete) a bigger task using Python. 
Your case were true, then where is the huge wealth of little games 
written by these people? (the list the Pygame site is nice, but far from 
huge/)

> In reality [python] is considerably slower than C itself. ... But 
> still, the game itself will be written in Python, and I think most 
> people underestimate it for that task.
Exactly. :)
I am still not sure why this belief that Python is unfit for the task 
exists. There is more than enough proof out there on the contrary - just 
scattered about.
Perhaps we need more information in one place on what 'successful' apps 
have been implemented with Python?
More proof that speed only matters in a very very small subset of 
applications, and even in those - only a small portion of it.

Or, perhaps I need to take a more Taoist approach as suggested?
Drop advocacy, in favor of inaction.
(Or, just write bigger and better apps and let the work speak for itself :P)

Yup.
          - Jacob