Earlier quoted context omitted.
Also, add a couple of type annotations to the program: 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).
Wouldn't just straight running this through cython make more sense? Or numba?
Node.js 14 is over 20x faster than Python3.8 for fib(n)
31–40 of 119 posts
Re: Node.js 14 is over 20x faster than Python3.8 for fib(n)
#32An 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…
I still prefer python over node though, but I can't deny the reality.
Re: Node.js 14 is over 20x faster than Python3.8 for fib(n)
#33An 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.
How does the JIT compilation help in terms of CPU bound work? Is node somehow able to automatically parallelize this code? I know cpython is limited to a single core unless you specifically use multiprocessing. Or is this related to something else?
Re: Node.js 14 is over 20x faster than Python3.8 for fib(n)
#34Python feels noticeably slower than Node.js, particularly when running scripts with large amounts of imports. I now pretty much always use JavaScript for, well, scripting. Not sure why Python and Ruby are considered go-tos there.
Edit: didn’t exist at the time!
Python is my go-to because I know the ecosystem well and can go from zero to done with minimal effort and research.
Node has since (come into existence) and matured, and while it may be better/faster in some situations now, I haven’t encountered a project that has compelled me to switch.
I suspect the answer to your question boils down to a combination of: familiarity, preference, individual productivity, and pragmatism.
This will likely shift over time.
Re: Node.js 14 is over 20x faster than Python3.8 for fib(n)
#35An 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.
How does the JIT compilation help in terms of CPU bound work? Is node somehow able to automatically parallelize this code? I know cpython is limited to a single core unless you specifically use multiprocessing. Or is this related to something else?
So it can emit extremely efficient instructions based on this assumption, while CPython struggles along with infinite precision numbers.
Function calls will have a much lower overhead also since it will just be a single `call` instruction.
Re: Node.js 14 is over 20x faster than Python3.8 for fib(n)
#36An 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…
Re: Node.js 14 is over 20x faster than Python3.8 for fib(n)
#37Re: Node.js 14 is over 20x faster than Python3.8 for fib(n)
#38An 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.
And why doesn't python's default runtime environment obviously come with a JIT then? I think they should absolutely go for it, given the huge user base of python.
Reasons like "but named functions can dynamically change" are not applicable, since JS has those same properties and can do it. They could start with optimizing the case where you call the same function over and over in a for loop.
An alternative python interpreter is also not the solution, normally what you have is the main standard python interpreter, and that is the one that should be fast, period.
Re: Node.js 14 is over 20x faster than Python3.8 for fib(n)
#39However, it does make me wonder, why has python become to standard for data science? Is it Library support or purely community based?
Re: Node.js 14 is over 20x faster than Python3.8 for fib(n)
#40Earlier quoted context omitted.
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…
Not only that, it wasn't until 3.9 that Python got optimizations for calling callables.