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. ":-)" > > > > > 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. -- http://mail.python.org/mailman/listinfo/python-list
