Py 2.5 on Language Shootout

[Isaac Gouy]

pgarrone at acay.com.au wrote:
> Alioth is a great site for selecting the language in which to implement
> primitives. Usually it's C.

And for selecting a language for which you might need to implement
primitives in C :-)

>
> Two of the alioth benchmarks, Partial-sums and Spectral-norm, could be
> done using Numarray, or would be done with Numarray if most of the
> program was in Python and there was a need to implement a similar
> numerical procedure. The speed would be up near the compiled language
> benchmarks. However the specific wording of these benchmarks prohibits
> this approach. Spectral-norm must pretend the dataset is infinite, and
> Partial-sums has to be implemented in a simple dumb loop.

And we wouldn't use a naïve recursive algorithm to find fibonnaci
numbers ... unless we were interested in recursion for its own sake.

Maybe the author of spectral-norm was interested in function calls.
Maybe the author of partial-sums was interested in simple dumb loops
and simple dumb Math.


> Looking over the benchmarks, one gains the impression that Python is a
> slow language.

What does that even mean - a slow language?


> My first serious Python programming exercise involved converting a 900
> line Bash Shell program to a 500 line Python program, with a speedup
> factor of 17. Using Python allowed an OO structure and advanced
> containers, meaning the program was more maintainable and portable,
> which were the main aims of the exercise. The speedup was a surprising
> and welcome side benefit. I think it was mosly because the Python
> byte-code interpreter is probably an order of magnitude faster than
> Bash's direct interpretation, and because in Python system calls to
> recurse directories and create symbolic links were not forked to
> separate processes. In fact I would guess that the overall speed of the
> Python program would be little less than a C program, given that most
> of the time would be spent in system calls.

/I would guess/

> Its almost possible to make a large Python program arbitrarily fast by
> profiling it and implementing slow bits as primitives. Size is probably
> of greater concern.

We could read that simply as - /it's not possible/ to make a large
Python program arbitrarily fast. Is that what you meant?