On Apr 18, 2008, at 1:31 PM, Michael George wrote:
True, although that constant is often on the order of 20, and 40 FPS
is a lot different than 2FPS.
--Mike
Casey Duncan wrote:
On Apr 18, 2008, at 9:23 AM, Ian Mallett wrote:
OK, my point here is that if C languages can do it, Python should
be able to too. I think all of this answers my question about why
it isn't...
C can do what? C is, at best, a constant time improvement in
performance over python. A bad algorithm in Python is also a bad
algorithm in C.
It's all well and good to think that Python should be as fast as C,
but no one is going to take you seriously unless you have a
specific proposal, preferably with an implementation that proves
its merit. Otherwise it's just wishful thinking.
But the larger point is that making things run faster is not an
panacea, reducing the algorithmic complexity is the best solution.
Make sure you have the best algorithm before you worry about
reducing the constant time factors.
The point (that's already been made, but I'll repeat it), is that a
better algorithm can achieve the same results without leaving Python.
When there is no better algorithm, then using a higher performing
language is about the only option you have for better performance.
There is an even better option, dedicated hardware, but that is far
beyond the reach of most mere mortals. But that's the reason why we
have things like SIMD instruction sets, GPUs and physics co-processors.
All this conjecturing about Python performance in relation to compiled
languages makes me wonder. Why is the performance of C code not as
good as that of well-written hand-coded assembler? Surely if the
machine can do it, C can?
The problem boils down to one of specificity. Any language that tells
the computer more specifically what to do can be faster than one that
doesn't. Unfortunately, telling the computer what to do specifically
is not a productive way to solve most problems. I'd rather not have to
tell the computer which machine codes to execute, but if I did, and I
was clever, I could make my program the fastest possible -- for a
given specific architecture at least.
Python is more abstract and general than C, C is more abstract and
general than machine code. Therefore machine code is potentially
faster than C, and C is potentially faster than Python. And unless you
reduce the generality of Python, it will always be possible to write
faster programs in C, given a competent compiler.
JITs (e.g., psyco) can help mitigating this, but they too are
ultimately constrained by Python's expressive power.
So unless you are proposing to reduce Python's expressive power, you
are waging a losing battle. Until which time machine intelligence
exceeds our own, it will always be possible for a human programmer to
get higher performance from the lower-level language. And I further
propose that when the time arrives that machine intelligence exceeds
our own, this will not be the problem foremost on my mind ;^)
-Casey
