Python vs. Lisp -- please explain

[Steven D'Aprano]

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.