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