On 23/02/2018 18:56, Chris Angelico wrote:
On Sat, Feb 24, 2018 at 5:43 AM, Python <pyt...@bladeshadow.org> wrote:
Satisfied?
No, not satisfied. Everything you've said would still be satisfied if
all versions of the benchmark used the same non-recursive algorithm.
Why? Does it matter?
There's nothing here that says it's testing recursion, just that (for
consistency) it's testing the same algorithm. There is no reason to
specifically test *recursion*, unless that actually aligns with what
you're doing. For instance, when Google Chrome rolled out its new V8
JavaScript engine, it was specifically optimized for recursion,
because many Google apps used recursion heavily. If you're
implementing a new LISP interpreter, you should probably optimize for
recursion, because most LISP code is going to be written recursively.
But otherwise, there's no particular reason to stick to recursion.
You list plenty of reasons, then say there's no reason to use recursion!
The recursion is a red herring; but to get a program with lots of
function calling, then using a recursive algorithm - any algorithm -
will do the job.
Would you have a different opinion if Python excelled at that benchmark,
and Julia sucked? (I can't remember what the results were.)
(I was testing one of my static compilers today; it has three call
convention modes all operating within the Win64 ABI. I used the
Fibonacci benchmark with fib(42) to test it, with these results:
mode 1 5.8 seconds (non-ABI)
mode 2 6.5 seconds (part ABI conformance)
mode 3 7.4 seconds (full ABI conformance)
Other compilers (C compilers that have to conform) ranged from 4.3 to
6.2 seconds, including MSVC/O2. Except for gcc-O3 which managed 1.7
seconds. How do it do that? I'll have to investigate to see how much it
cheated.
The point of all this: I was using the recursive Fibonacci benchmark for
these tests, as there is little else going on besides function calls and
returns. It's perfect.
Why some people hate it here, I really don't know.)
I won't dispute that part. The correct way to do this would be to
optimize both sides fairly - either not at all, or equivalently (for
some definition of equivalence). But switching both sides to an
unoptimized iterative algorithm would be perfectly fair. Recursion is
NOT essential to the benchmark.
So, what benchmark would you use instead if you wanted an idea of how
well each language dealt with it?
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
