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

[bartc]

On 26/02/2018 19:50, Chris Angelico wrote:
> On Tue, Feb 27, 2018 at 6:37 AM, Rick Johnson

>> So what? Latency is latency. And whether it occurs over the
>> course of one heavily recursive algorithm that constitutes
>> the depth and breadth of an entire program (a la fib()), or
>> it is the incremental cumulative consequence of the entire
>> program execution, the fact remains that function call
>> overhead contributes to a significant portion of the latency
>> inherent in some trivial, and *ALL* non-trivial, modern
>> software.

Take the last bit of Python I posted, which was that RNG test.

It uses this function:

   def i64(x): return x & 0xFFFFFFFFFFFFFFFF

This is a small function, but it can't be a toy one as it was suggested 
by Ned Batchelder. And the test program wasn't at all recursive.


Running the program with N=10_000_000 took 46 seconds.

Replacing the i64() call with '&m' (where m is a global set to 
0xFFFFFFFFFFFFFFFF), it took 38 seconds.

So putting that fix into a function, which is convenient for coding, 
maintenance and readability, cost 20% in runtime.

Going the other way, having i64() call another function i64a() which 
does the work, common when using wrapper functions, it took 60 seconds. 
A 30% slowdown, even though most of the work is doing numeric shifts and 
adds.

So function calls do seem to be expensive operations in CPython, and any 
benchmarks which highlight that fact should be welcomed.

(Note than none of this seems to affect PyPy, which ran at the same 
speed with i64(), without it, or with both i64() and i64a().)

-- 
bartc