Live data from Hacker News

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

jott.live

41–50 of 119 posts

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

#41

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.

Because not all scripting has strict performance requirements, and as much as I love JavaScript, Python blows it out of the water in scripting ergonomics and semantics IMO.

Opening / reading / writing files, parsing args, making HTTP requests, etc. which are extremely common scripting operations are easier with Python, and the end result tends to be much more succinct thanks to its syntax (this applies to all Python code compared to JavaScript, but I'd argue it's especially valuable in shorter scripts).

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

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

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!

If I’m writing an article about benchmarking, then yes.

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

#44

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.

For a lot of workloads, performance is less important than maintainability. Python's cultural and technical adherence to an ideal code structure makes it a good candidate for long-haul code where CPU-bound performance isn't going to be a factor.

IMO the opposite end of that particular scale is Perl.

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

#45
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 sa…

> And why doesn't python's default runtime environment come with JIT? I think they should absolutely go for it, ensure the default python you get when you run python has a JIT, given the huge user base of python.

1. because CPython aims to be relatively simple and straightforward by choice

2. because the "huge user base" comes in large parts from the deep and extensive C API, which is absolute hell on a JIT

3. because most of the userbase would not give a shit anyway, it has not exactly migratd en masse to pypy: much of the userbase sees and uses Python as a glue language, Python is an interface to optimised C routines without being a pain in the ass to develop in.

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

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

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!

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!

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

#47

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

Numba version:

    @numba.jit
    def fib(n):
      if n == 1 or n == 0:
        return 1
      return fib(n - 1) + fib(n - 2)
first run:

498.46601486206055 ms.

second run:

89.19310569763184 ms.

For completeness, with njit:

    @numba.njit
    def fib(n):
      if n == 1 or n == 0:
        return 1
      return fib(n - 1) + fib(n - 2)
first run:

152.62889862060547 ms

second run:

86.35592460632324 ms

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

#48
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?

Crossing the interpreter-native-code domain is expensive, primarily because of poor cache usage.

You want to be either full JIT compiled code, or vice versa have as much interpreter functions, and libraries written in native code, and style the API to avoid loops.

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

#50

Earlier quoted context omitted.

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.

Both numba and cpython work with python code AFAIK.

I don't know that cpython would take advantage of mypy annotations and you can make a cpython program not python-compatible, but you don't have to.

Post reply on HN