On Fri, Feb 23, 2018 at 01:38:01AM -0500, Terry Reedy wrote: > It is no secret that Python's interpreted function calls are slower > than function calls compiled to machine code and that Python's > infinite precision integer arithmetic is slower that machine int > arithmetic. So there is almost no point in combining both in a > naive drastically inefficient algorithm and declaring that Python is > slower.
I never said the benchmarks chosen were awesome... :-) What I'm saying is this: 1. Insistence that the most efficient python implementation of Fib completely misses the point (and defeats the purpose) of the benchmarks, and as such the entire article is lost in the weeds. 2. Inasmuch as someone might want to measure the performance of recursive function calls in a particular language, the choice of recursively implementing fib is a fine one, and useful for that purpose. 3. If you want to say that choosing the most efficient implementation in Python is the only way to do a fair comparison, then you must also choose the most efficient implementation in Julia, which this is not, by all appearances. But again, this misses the point of the benchmark and defeats its purpose. Now if you want to complain that the purpose is silly, I won't even argue that... In 30 years of writing code I don't think I've ever imiplemented a recursive solution to any problem that wasn't purely academic. Maybe once or twice... maybe. But the purpose is what it is, and arguing that it must be done a different way is bogus. -- https://mail.python.org/mailman/listinfo/python-list
