I'm honestly not too surprised. I follow the v8 blog and they talk extensively about performance improvements on most releases.
If you can trust language benchmarks, you only get notable performance benefits when switching from JS to Rust/C/C++.
11–20 of 119 posts
I'm honestly not too surprised. I follow the v8 blog and they talk extensively about performance improvements on most releases.
If you can trust language benchmarks, you only get notable performance benefits when switching from JS to Rust/C/C++.
An interpreter with a JIT is obviously faster than one without. Especially when dealing with CPU bound work. I'm not sure this is entirely noteworthy unless you somehow think CPython has a JIT. Would be much more interesting to compare to pypy.
pypy test.py
305.4699897766113 ms node test.js
111.49054491519928 ms python3 test.py
3576.0366916656494 msNode still wins by a healthy margin.
Doesn't the Node.js version use double precision floating point vs python using infinite precision integers ? That would explain part of the difference in performance, and make the python version exact, but js version inexact.
Doesn't the Node.js version use double precision floating point vs python using infinite precision integers ? That would explain part of the difference in performance, and make the python version exact, but js version inexact.
An interpreter with a JIT is obviously faster than one without. Especially when dealing with CPU bound work. I'm not sure this is entirely noteworthy unless you somehow think CPython has a JIT. Would be much more interesting to compare to pypy.
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 m…
"Obviously this isn't the most comprehensive benchmark, but the results are surprising to me."
I fully agree with this and I learned something new about cpython's weakpoints today!
FYI: pypy3 is 10x faster than CPython on this benchmark. ~> python fib.py 4825.7598876953125 ms ~> pypy3 fib.py 514.7459506988525 ms
import time
def fib(n: int) -> int:
if n == 1 or n == 0:
return 1
return fib(n - 1) + fib(n - 2)
t0 = time.time()
fib(35)
t1 = time.time()
print(f"{(t1 - t0) \* 1000} ms")
The run: ~> mypyc fib.py
And boom: ~> python
>>> import fib
332.64994621276855 ms
(FYI, mypyc is a compiler that's part of the mypy package).Doesn't the Node.js version use double precision floating point vs python using infinite precision integers ? That would explain part of the difference in performance, and make the python version exact, but js version inexact.
I prefer the JS approach.