[EMAIL PROTECTED] wrote: > Isaac Gouy wrote: > > [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
