How to make Python run as fast (or faster) than Julia
bartc
bc at freeuk.com
Fri Feb 23 14:36:39 EST 2018
On 23/02/2018 18:56, Chris Angelico wrote:
> On Sat, Feb 24, 2018 at 5:43 AM, Python <python at 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
More information about the Python-list
mailing list