Live data from Hacker News

Node.js 14 is over 20x faster than Python3.8 for fib(n)

jott.live

31–40 of 119 posts

Re: Node.js 14 is over 20x faster than Python3.8 for fib(n)

#31

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?

Well, a point in mypyc’s favor is that the above code is still syntactically valid Python code.

Re: Node.js 14 is over 20x faster than Python3.8 for fib(n)

#32
post #4
post #2

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…

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.

Re: Node.js 14 is over 20x faster than Python3.8 for fib(n)

#33
post #10
post #2

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.

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?

Python 3 uses interpreted bytecode, it’s faster than running an interpreter over an AST but much slower than using raw machine code. For most things people use Python for this is fine, especially since there are many extensions to do cpu-intensive tasks written in C.

Re: Node.js 14 is over 20x faster than Python3.8 for fib(n)

#34

Python 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.

I’ve been scripting in Python since 2003. Node wasn’t mature/viable at the time.

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)

#35
post #10
post #2

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.

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?

JITs work based on assumptions that types/values will stay constant. So, here it probably assumes that it will always be working with integers. So it will be much more efficient in cases like this as it is pretty much pure, simple computation. At worst there could be one deoptimisation when it moves from 32-bit to 64-bit integers, if v8 uses 32-bit integers first.

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)

#36
post #4
post #2

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…

Not only that, it wasn't until 3.9 that Python got optimizations for calling callables.

Re: Node.js 14 is over 20x faster than Python3.8 for fib(n)

#38
post #2

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.

> An interpreter with a JIT is obviously faster than one without.

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)

#40
post #4

Earlier 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.

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.
Post reply on HN