Theoretical threshold of improving Python's performance

[dalf]

Siegfried Gonzi <siegfried.gonzi at kfunigraz.ac.at> wrote:
> 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?".

> 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.

  No.
  For static compilation (i.e. you completly compile the program before
running it), it is likely that Common Lisp is faster.

  But, thanks to Just-In-Time compilation methods, you are not bound
to static compilation ; then you could go arbitrary close to Lisp or
faster. It amounts to, among other things, what amount of type information
the JIT Python is able to guess. Example, if your code is doing 99% of its
processing on lists of size 4 with ints (and 1% with more arbitrary lists),
in the most ideal case, your JIT engine could detect this, generate code
using SIMD Pentium III+ assembly instructions, with vectors of 4 x 32 bits,
using a fast test and bailout for the 1% of the "arbitrary lists" cases.
  Not that it is easy, but it isn't impossible. Look how efficient are some
Java JIT.

.dalf