How to make Python run as fast (or faster) than Julia

[bartc]

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