Theoretical threshold of improving Python's performance

Michael Hudson mwh at python.net
Fri Apr 5 08:42:56 EST 2002


Siegfried Gonzi <siegfried.gonzi at kfunigraz.ac.at> writes:

> I got a private email where I can read that Python can be never made
> as fast as Common Lisp due to Python's dynamic nature. May I ask
> without any ulterior-motive: "Has the beformentioned proposition any
> value?".

Never is a long time.  Python's dynamism would seem to make it harder
to get to CL-type speeds, but impossible?  I don't think that's a
question that can be meaningfully answered.

> I know there were discussion concerning the topic; but I would be really
> interested in, from a theoretical point of few, whether it is a *fact*
> that Python can *never* become as fast as Common Lisp* or not.

See above.  Note the woolly vagueness of my comments :)

> I think it is documented that I am not really (maybe until yet)
> striving for a faster Python (clearly, would not say no) but I am
> really interested in and a little bit clueless whether Python is
> really much more dynamic than Common Lisp and this is an upper
> threshold.

Python probably is somewhat more dynamic that Common Lisp.  For
example, in Python, dicts use __eq__ methods; in Common Lisp, hash
tables are restricted to eql, equal and equalp (I think -- a bunch of
equality predicates that you can't override on your own types, in any
case).

Also, cl:+ similarly isn't extensible (and doesn't concatenate
strings), etc.

I don't know how much practical difference this makes -- some, but not
a lot, would be my guess.  Avoiding runtime method resolution is
something CL compilers work hard at, I think.

> *[I got some complaints that I sometimes stress the 10 times Common Lisp
> performance hit; if some experienced profi programmer can tell me that
> he is using Common Lisp in combination with declaring variables on a
> daily basis I am going to quit my rants immediately]

Not sure what you mean by "profi", but when I wrote a uni assignment
in CL, I declared most of my variables (possibly too many, in fact).
It's the only way to get CMUCL's compiler to shut up when you (declare
(optimize (speed 3) (safety 0)), for one thing...

Cheers,
M.

-- 
  Not only does the English Language borrow words from other
  languages, it sometimes chases them down dark alleys, hits
  them over the head, and goes through their pockets.   -- Eddy Peters



More information about the Python-list mailing list