Py 2.5 on Language Shootout

[Isaac Gouy]

pgarrone at acay.com.au wrote:
> 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. ":-)"

iirc I've never written a program in C or C++ (although I may have
fixed one or two that someone else wrote).


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

I'm confident in my ability to misunderstood the point someone intended
to make - I think your point is some variation on 'we wouldn't write
the program like that' '"real-world" programs aren't like that'.


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

Unless we notice that sometimes there's more than one language
implementation for some languages; unless we notice that sometimes
there's more than one program for the same language implementation.
(Unless we read the bold text on the homepage.)


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