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

[bartc]

On 24/02/2018 02:46, Steven D'Aprano wrote:

> Take the Fibonacci double-recursion benchmark. Okay, it tests how well
> your language does at making millions of function calls. Why? How often
> do you make millions of function calls?

Very often. Unless you are writing code 1970s style with everything in 
one big main function.

I've done some tests with my interpreter [sorry, Ned], on one real task:

   Total number of byte-code calls: 3.2 million
   Total number of real x64 calls: 520 million

On this specific benchmark: 48 million and 580 million.

Changing the way those x64 calls were made (using a different call 
convention), made some byte-code programs take up to 50% longer to 
execute. [In this interpreter, each byte-code, no matter what it is, is 
dispatched via a function call.]

  For most application code,
> executing the function is far more costly than the overhead of calling
> it, and the call overhead is dwarfed by the rest of the application.

Any actual figures?

In the case of interpreters, you want to optimise each byte-code, and 
one way of doing that is to write a small program which features that 
byte-code heavily. And then you start tweaking.

It is true that when working with heavy-duty data, or offloading work to 
external, non-byte-code functions, then the byte-code execution 
overheads are small. But Python's weakness is when it /is/ executing 
actual algorithms using actual byte-code.

And actually, performance of CPython does seem to have improved 
tremendously over the years. So some people have their eye on the ball. 
Clearly not you.

> If you have a language with tail recursion elimination, you can bet
> that's its benchmarks will include examples of tail recursion and tail
> recursion will be a favoured idiom in that language. If it doesn't, it
> won't.

Benchmarks need to be honest. But Fibonacci I think can't use that 
optimisation (although gcc seems to have found another way of not that 
much work).

-- 
bartc