A faster Python?, Python compiler, Dylan,...

[Siegfried Gonzi]

Jan Kybic wrote:

> In my field (signal and image processing) and on high-level tasks,
> Python+Numeric runs at the same speed as the equivalent Matlab code.
> I have one big application that I basically wrote twice for both
> platforms and that's the conclusion I made.
> 
> On the other hand, all the calculation that you cannot express using
> high-level primitives (using matrices, vectors,...) and has to be
> performed with loops element by element, is painfully slow. Equally
> slow in Python, as in IDL, Matlab,... 

Not splitting hairs here: but IDL and Yorick are faster than Matlab when
it comes to loops!

>It is so slow that it is
> unusable, it is very difficult to develop an algorithm if it takes
> days to process any reasonably sized input. My solution is to rewrite
> the critical part of the code in C/C++, I did this for Matlab,
> Python+Numeric, as well as IDL, but this is awkward - 

Good to see that my assumption that Numeric is not slower than Matlab or
IDL can be confirmed.

> it forces you to
> work simultaneously with two languages and to deal besides the algorithm
> itself with a lot of implementation and interface details.
 
Dubois dubbed this "steering your code". I do not have got much
experience at this field (foreign functions). But why do you think that
steering code is in the long run not the panacea? 

> I would love to hear your thoughts on the subject.

I am with (who not would acknowledge a faster Python?) you on the
subject.  I am not a computer scientist and will not go to propose how
to make Python faster. There were threads which discussed the topic.
Often Common Lisp is strained as a model for a faster Python. Common
Lisp (compiled) normaly is about 10 times slower than an equivalent C
code (you can declare Lisp variables --and these would boost you in the
2 times slower than realm of C or Fortran--but declaring variables in
Lisp is a different story and science and for normal users quite hard to
manage).

I think the question actually is more or less: would you be contented
with a Python which produces compiled code which in turn executes 10
times slower than an equivalent C code? Normally, Python executes code
about 100 times slower than C.

And the next question: It is feasible to improve Python to that level?
You may not forget that people -- even when Python improves from a 100
times to 10 times performance penalty -- then will also compare it to C
or Fortran and the 10 times performance hit remains!

It would be a pity if one is investing much time in improving Python but
has to recognise that people always will point to the 10 times
performance hit compared to lets say C (Common Lisp coders are faced
with that problem every day).


> Jan Kybic <kybic at ieee.org>      Robotvis, INRIA, Sophia-Antipolis, France

What about your experience with Scilab? Or even due to INRIA: OCaml?


S. Gonzi