Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

jott.live

Post reply on HN
Print view View original

91–100 of 119 posts

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

#91

Post by ak217 »

nemothekid wrote: post #74
Aardwolf wrote: post #38

Earlier quoted context omitted.

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

Armin Ronacher, author Flask, actually has a good talk about this. The gist of it the way Python's internals leak into the language makes it very difficult to build a performant JIT that wouldn't break a large amount of userspace code. Python lets you do _far_ more shenanigans that Javascript does; and a lot of large libraries depend on some of that behavior. Breaking it would probably cause a new 2 -> 3 situation. h…

> a lot of large libraries depend on some of that behavior.

Armin makes great points about path dependence of API design and how the CPython API leaks into the Python language spec. But the features being discussed are actually obscure (example: slots) or intended for debugging (example: frame introspection), and most libraries don't have a good reason to use them. We're stuck in a loop: people talk about how Python is special and can't use a JIT because its internals are not JIT-friendly, so we don't have a JIT, so implementers continue to make choices that are not JIT-friendly - not because they want to, but because they have no guidance.

The JIT doesn't have to be amazing on day 1. What it does have to do is show a commitment and a path to performant code, and illuminate situations where optimizations turn off. There's nothing fundamental in Python's design that prevents a JIT from working; a small number of rarely used dynamic features (that most people don't know about and don't know that they can negatively affect performance) should not be used to hold up interpreter design.

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

#93

Post by tuckerconnelly »

wongarsu wrote: post #29
tuckerconnelly wrote: post #12

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.

Python gives you better escape hatches for typical compute-heavy work (lots of libraries use C under the hood), and Python has a better multi-threading story than Node.js. But I guess the biggest differentiators are really the ecosystems and standard libraries. Node.js is certainly catching up, but Python has generally a better selection of high-quality libraries for tasks beyond the web.

Lack of library support is probably the most valid reason here. Most of the other reasons people have posted seem like opinions on ergonomics. I think those held true 10 years ago, but modern JavaScript feels very minimal and lisp-y and is more enjoyable to program with than Python IMO.

What libraries or escape hatches to you actually use in your daily work that are exclusive to Python? The ones I'm familiar with would probably be OpenCV and the whole machine-learning family of libraries (sci-kit, spacy, tensorflow, etc).

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

#94

Post by contravariant »

maxmaio wrote: post #69

I know it's not super relevant to node vs python3, but your fib(n) has a time complexity of O(2^n)... with a dp approach it can be solved in O(n). also your space complexity can be reduced to O(1).

With a better chosen dp approach you can even solve it in O(log(n)). Though at that point the extra cost of multiplying large integers becomes non-negligible.

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

#95

Post by contravariant »

davesque wrote: post #68

1. Python doesn't have a JIT. This shouldn't be surprising or headline worthy. 2. Why benchmark an O(2^n) fibonacci? It's basically benchmarking call frame creation. 3. A single order of magnitude is honestly not that impressive a speedup for JIT vs. no JIT. Might have a lot to do with the inefficiency of the recursive fibonacci func. Also, to quote another poster: @numba.njit def fib(n): if n == 1 or n == 0: return…

Of course in the category of 'single line' performance optimizations the most effective one is going to be:

    @lru_cache(1000)
    def fib(n):
        if n == 1 or n == 0:
            return 1
        return fib(n - 1) + fib(n - 2)
which lowers the time to somewhere around 20 microseconds.

I'd be interested to know if Node.js can do anything similar.

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

#97

Post by williamstein »

masklinn wrote: post #28
fermigier wrote: post #18

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?

Here are some timings using three different approaches using Cython, and also numba: https://share.cocalc.com/share/df81e09e5b8f16f28b3a2e818dcdd...

Numba wins and is about twice as fast as my most clever Cython code. Naive Cython is pretty bad, but more clever Cython is reasonably good (though not as good as numba).

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

#98

Post by GuB-42 »

CivBase wrote: post #85
GuB-42 wrote: post #83

Earlier quoted context omitted.

I think it matters because a lot of people are doing math in python. And if good optimizations can help run a small simulation in 1 minute instead of 2, multiplied by the number of python users, it is a lot of time gained. And I suspect, the fib(n) situation is actually quite common. I mean, not everyone who writes python is a "real" developer, there are a lot of scientists who just want the computer to run their for…

Yeah, but it's like comparing the effectiveness of a shovel vs a spade when it comes to hammering nails. You should obviously use a hammer. If it's not worthwhile to get a hammer, then does it really matter whether you use the shovel or the spade?

If a lot of people use a shovel as a hammer, the people making shovels should start considering that use case. The spade manufacturers already did so they could take inspiration.

Real life tool manufacturers take "wrong" use into account. One of my preferred anecdote is the IMI Galil assault rifle, which has a built-in bottle opener. It was done because they noticed soldiers used magazines to open bottles, and it could cause damage.

Of course, it is not about choosing between a shovel and a spade, people who have a choice will use a hammer. But it doesn't mean we shouldn't do a favor to shovel bearers.

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

#99

Post by CivBase »

GuB-42 wrote: post #98
CivBase wrote: post #85

Earlier quoted context omitted.

Yeah, but it's like comparing the effectiveness of a shovel vs a spade when it comes to hammering nails. You should obviously use a hammer. If it's not worthwhile to get a hammer, then does it really matter whether you use the shovel or the spade?

If a lot of people use a shovel as a hammer, the people making shovels should start considering that use case. The spade manufacturers already did so they could take inspiration. Real life tool manufacturers take "wrong" use into account. One of my preferred anecdote is the IMI Galil assault rifle, which has a built-in bottle opener. It was done because they noticed soldiers used magazines to open bottles, and it cou…

But what's the implication here if not that people should use JavaScript for better performance? That the Python Software Foundation should invest more in the performance of the reference interpreter, CPython?

The Galil magazine example has an obvious, easy-to-implement, low-cost solution with an obvious ROI. If that weren't the case, don't you think IMI would have just cautioned soldiers about potential damage to the magazines and instructed them to use a bottle opener instead?

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

#100

Post by Sohcahtoa82 »

nemothekid wrote: post #74
Aardwolf wrote: post #38

Earlier quoted context omitted.

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

Armin Ronacher, author Flask, actually has a good talk about this. The gist of it the way Python's internals leak into the language makes it very difficult to build a performant JIT that wouldn't break a large amount of userspace code. Python lets you do _far_ more shenanigans that Javascript does; and a lot of large libraries depend on some of that behavior. Breaking it would probably cause a new 2 -> 3 situation. h…

> Python lets you do _far_ more shenanigans that Javascript does

Does JavaScript let you do this monstrosity of terrible code?

    Python 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> class Dog(object):
    ...     def speak(self):
    ...             print("bark!")
    ... 
    >>> class Cat(object):
    ...     def speak(self):
    ...             print("meow!")
    ...
    >>> animal = Dog()
    >>> animal.speak()
    bark!
    >>> animal.__class__ = Cat
    >>> animal.speak()
    meow!
    >>>
Post reply on HN