How to make Python run as fast (or faster) than Julia
bartc
bc at freeuk.com
Sat Feb 24 06:35:17 EST 2018
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
More information about the Python-list
mailing list