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