Py 2.5 on Language Shootout

[pgarrone at acay.com.au]

Isaac Gouy wrote:
> 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 :-)

Well if you like C so much, just do it 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.

I am not disputing this. I think you take my point though.

>
>
> > Looking over the benchmarks, one gains the impression that Python is a
> > slow language.
>
> What does that even mean - a slow language?
>

The alioth benchmarks provide a set of numbers by which
languages may be compared.

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

I don't have the time, or interest, to recode it in C to find out.
In reality the choice would be C++ because of OO and STL.
Perhaps traversing and linking a tree containing about 1000 files would
not
take a full second. I might be wrong. All i know is, its a lot faster
than Bash.

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

No. I meant that if my Python program is too big in terms of its
execution memory
requirements, then that would be a difficult issue to deal with. Rather
than
optimizing execution hotspots, I might have to use another language.

Cheers,
 P.S. Alioth is a great site.