On Wed, 22 Feb 2006 10:15:21 +0100, Torsten Bronger wrote: >> And, as someone in this thread has pointed out, it is likely that >> your important modern (x86) processor is not natively executing >> your x86 code, and indeed meets your definition of having "in its >> typical implementation an interpreting layer necessary for typical >> hardware". > > Only if you deliberately misunderstand me.
If the words you choose to use have implications which you failed to realise before saying them, don't blame the reader for spotting those implications. >> Another example: is Java the bytecode, which is compiled from Java the >> language, interpreted or not? Even when the HotSpot JIT cuts in? > > It is partly interpreted and partly compiled. That's why it's faster > than Python. But Python is partly interpreted and partly compiled too, so that can't be the answer. I think we all know what the answer is. The Python interpreter isn't as fast as the Java interpreter, or most machine code interpreters built into hardware. On the other hand, I'm pretty sure that interpreted Python runs faster on my current PC than compiled code runs on the 20 year old Macintosh in my cupboard. So "compiled" isn't a magic wand that makes code run faster. >> [...] >> >> Personally, in practice I don't care, so don't ask me. Ponder on >> getting angels to dance on the head of a pin before you worry about >> whether the dance can be interpreted or not. > > I agree that the term "interpreted" is bad Python advocacy because its > implications are often misunderstood. However, I think that it's fair > to make a distiction between compiled and interpreted languages because > it may affect one's decision for one or the other. Although I'm surely > not ingenious, I can make this distinction. Would you rather use a blindingly fast interpreted language, or a slow-as-continental drift compiled one? This isn't a rhetorical question. In the mid-80s, Apple and Texas Instruments collaborated on a Macintosh II computer with a Lisp coprocessor. The problem was, according to benchmarks at the time, Lisp compiled and run natively on the coprocessor was actually slower than Lisp interpreted on a standard Macintosh II. I'm sure that's hardly the only example of a speedy interpreted language beating a glacial compiled one. > The reason why Python is slower than C is because there is an > interpreting layer that C doesn't have. The primary reason Python is slower than C is because C compilers have been optimized to create fast code, while Python has been created to optimize programmer productivity instead. That means that a simple instruction like x + y does a lot more work in Python than it does in C. There are other languages that, like Python, are dynamic, interpreted, interactive and the rest, and they execute faster than Python. (By the same token, there are also some that execute slower than Python.) Let's be honest here: it isn't that Python can't be as fast as C, it is that the Python Dev team have had other priorities. But over time, as PyPy, Psycho, and other technologies bear fruit, Python will speed up, even though it will remain interpreted. > And the reason for this is that > Python's nature is incompatible with today's CPUs (which was a > deliberate and advantageous design decision). I'm sure that a willing > CS person could define this more clearly. > > Anyway, if we drop "scripting" and drop "interpreted", what do you want > to tell people asking why Python is so slow? Because it is dynamic? ;-) Who says Python is so slow? I've just got Python to count from 0 up to 100,000, and it only took 7 milliseconds. That's at least 12 milliseconds faster than I can count on my fingers. But seriously... why not tell them the truth? Python is slower than some other languages because optimization for execution speed has not been the primary focus of Python's development. If you tell them that Python is slow because it is interpreted, they will believe that Python will always be slow. If you tell them that Python is slow because speed has not been the priority, they will believe that some day it will become the priority, and then Python will get faster. And they will be right. That is the aim of PyPy after all. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
