Live data from Hacker News

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

jott.live

11–20 of 119 posts

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

#11

I'm honestly not too surprised. I follow the v8 blog and they talk extensively about performance improvements on most releases.

V8 is a monster.

If you can trust language benchmarks, you only get notable performance benefits when switching from JS to Rust/C/C++.

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

#13
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.

  pypy test.py 
305.4699897766113 ms

  node test.js      
                 
111.49054491519928 ms

  python3 test.py     
       
3576.0366916656494 ms

Node still wins by a healthy margin.

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

#14

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.

That's one factor but there is an overall reason behind performance difference. The main reason is v8 and the inordinate amount of resources google has thrown against that thing to make it ultra fast. You should read up on the people who work on it.

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

#16

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.

The numbers are small so there shouldn’t be any difference for fib(35)

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

#17
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…

Seems like an unduly harsh take. Is everyone just supposed to inherently know this fact about cpython or find it unsurprising when they run across it?

"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!

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

#18

FYI: pypy3 is 10x faster than CPython on this benchmark. ~> python fib.py 4825.7598876953125 ms ~> pypy3 fib.py 514.7459506988525 ms

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

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

#20

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.

This is correct, though both are exact at the scales in question (14930352). There's a more general question of whether it's beneficial to take a perf hit for all arithmetic in order to support some corner cases of infinite precision, or be explicit that standard arithmetic won't be precise, but you can opt into it via some mechanism (BigNum, in the JS case)

I prefer the JS approach.

Post reply on HN