Indeed. Furthermore this basically just benches function call overhead by using the worst possible implementation of fib().
Function call is a well-known weak point of cpython, even amongst all its other weak points performance-wise.
It's hard to express how utterly uninteresting and useless TFA is, and if its author is surprised by the result… really the only component this tells us about is the author.
> Would be much more interesting to compare to pypy.
I'm not sure it is more interesting at all, let alone much more, but here are the results on my (obviously much slower than TFA's) machine:
> python3.9 --version
Python 3.9.1
> python3.9 fib.py
8555.904865264893 ms
> pypy37 --version
Python 3.7.9 (7e6e2bb30ac5fbdbd443619cae28c51d5c162a02, Jan 15 2021, 06:03:20)
[PyPy 7.3.3-beta0 with GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)]
> pypy37 fib.py
715.0719165802002 ms
> node --version
v14.15.4
> node fib.js
247.19056797027588 ms
(can I note that the 12 decimal precision of the script is hilarious? Because clearly when you're benching fib(35) you need that femtosecond-scale precision)
It does seem a bit harsh, but I would put it like this: If you need to care about performance, then this is an extremely basic difference between the two language implementations that should not surprise you. If you don’t yet, then this is the very beginning of your education in how to care about performance—welcome to the next level!
Oh, I think it is a quite reasonable comment. It isn't interesting work being done in the benchmark and the benchmark itself is short.
If you want to get ultimate performance from Python then write a C function...
If you want to inform me about runtime performance then show me how the language runtimes are spending cycles. If you wish to convince me about a language being great then tell me about the engineering effort to create and then run something in production.
It's a 2 sentence post, the latter of which seems to be trying to dispel the idea that it's about what you're implying it is. Uninteresting to experts in the area that consider this common knowledge maybe, not a failure of the author to do something worthwhile though.
These details aren't important. It's like bench marking C++ and node and then complaining about implementation details. Node should be and is definitively faster then python in practically every bench mark.
I still prefer python over node though, but I can't deny the reality.
Doesn't really matter, I ran it on 3.9, it's still slow. Between the kind of language Python is and the optimisation CPython allows for itself, there is simply no way it could be competitive.
Function call is a well-known weak point of cpython, even amongst all its other weak points performance-wise.
It's hard to express how utterly uninteresting and useless TFA is, and if its author is surprised by the result… really the only component this tells us about is the author.
> Would be much more interesting to compare to pypy.
I'm not sure it is more interesting at all, let alone much more, but here are the results on my (obviously much slower than TFA's) machine:
(can I note that the 12 decimal precision of the script is hilarious? Because clearly when you're benching fib(35) you need that femtosecond-scale precision)