python speed

[David Rasmussen]

Peter Hansen wrote:
>>
>>> From the speed requirement: Is that correspondance chess by any chance??
>>
>> Regular chess at tournament time controls requires speed too. Any pure 
>> Python chess program would lose badly to the best C/C++ programs out 
>> there now.
>>
>> I would also like to see Half Life 2 in pure Python.
> 
> True, but so what? 

So nothing. I was just commenting on the correspondance chess comment... 
with a valid observation.

> Why did you suddenly change the discussion to 
> require "pure" Python?

Because that's the only meaningful thing to discuss. If we're allowed to 
use Python as a thin layer above C (a very important, practical and cool 
feature), then we're measuring the speed of C, not Python. What would be 
the point of that? I can already answer how fast that notion of Python 
is: as fast as C.

> And are you not allowed to use any of the 
> performance-boosting techniques available for Python, like Pyrex or 
> Psyco?

Of course.

> Why such restrictions, when these are things Python programs use 
> on a daily basis: these are *part* of Python, as much as the -O switch 
> on the compiler is part of C/C++.
> 

Because we're then measuring the speed of C, not Python. But if you want 
to convey the point that Python can be used for arbitrarily performance 
"hungry" problems, you're right. Just code the "fast" parts in C or 
assembly language and apply a thin layer of Python on top. Lather, 
rinse, repeat.

> Okay, let's compare a "pure" Python program (if you can define it in any 
> meaningful, practical way) with a "pure" Java program, running on a 
> non-JIT interpreter and with optimizations turned off (because, of 
> course, those optimizations are umm... somehow.. not "pure"...?).
> 

Says who? And why are you comparing to Java now? Java sucks.

> Judging by the other posts in this thread, the gauntlet is down: Python 
> is faster than Java.

I don't disagree with that.

> Let those who believe otherwise prove their point 
> with facts, and without artificially handcuffing their opponents with 
> non-real-world "purity" requirements.
> 

You are the one getting theoretical and academic. I was just commenting 
on the chess comment above, because it is a field that I have extensive 
knowledge in. To make a real-word challenge to make my point obvious:

Write a chess program in Python and win more than 50% out of 100 games 
against a good chess program (Crafty, Fritz, Chess Tiger etc.) playing 
on the same hardware. In fact, just win one.

Now, if you write the "fast" parts in C, you obviously can solve this 
problem, and easily. But then there is no reason to discuss Python's 
speed ever. Just say "as fast as C" and code everything in C and make a 
hookup in Python. In fact, why not just code it in C then?

/David