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

111–119 of 119 posts

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

#111

Post by thu2111 »

ak217 wrote: post #65
masklinn wrote: post #45

Earlier quoted context omitted.

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

> because CPython aims to be relatively simple and straightforward by choice Sacrificing performance for core interpreter developer convenience may have been the right choice when Python was getting started; it's no longer the right choice today. Today it's short-sighted. > because the "huge user base" comes in large parts from the deep and extensive C API, which is absolute hell on a JIT We can have both a JIT and a…

We can have both a JIT and a "deep and extensive" (or more importantly, stable) native API, as demonstrated by node.

Yes, but not that native API. Designing a native API that doesn't create huge problems later is difficult. The JVM, .NET and V8 guys managed it (mostly) but the scripting languages generally didn't. Their API is just literally the entire internals of the interpreter.

Figuring out how to JIT code in the presence of native extensions that expect the implementation to work in exactly the same way it always worked is a research problem. The only people who have got close to solving it are the GraalVM guys. They do it by virtualising the interpreter API and also JIT-compiling the C code! They run LLVM bitcode on the same engine that runs the scripting engine.

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

#112

Post by thu2111 »

ak217 wrote: post #91
nemothekid wrote: post #74

Earlier quoted context omitted.

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…

GraalPython is on its way to solving this, by co-JIT-compiling both Python and the code of the native extensions simultaneously. However Python is a large language and ecosystem, so it'll take a while for the implementation to mature.

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

#113

Post by ak217 »

thu2111 wrote: post #111
ak217 wrote: post #65

Earlier quoted context omitted.

> because CPython aims to be relatively simple and straightforward by choice Sacrificing performance for core interpreter developer convenience may have been the right choice when Python was getting started; it's no longer the right choice today. Today it's short-sighted. > because the "huge user base" comes in large parts from the deep and extensive C API, which is absolute hell on a JIT We can have both a JIT and a…

We can have both a JIT and a "deep and extensive" (or more importantly, stable) native API, as demonstrated by node. Yes, but not that native API. Designing a native API that doesn't create huge problems later is difficult. The JVM, .NET and V8 guys managed it (mostly) but the scripting languages generally didn't. Their API is just literally the entire internals of the interpreter. Figuring out how to JIT code in the…

Thanks for the context, those are great points.

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

#114

Post by knighthack »

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…

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

I completely disagree.

Your example of soldiers and their multi-tool use falsely conflates utility with necessity.

First, civilians generally don't have access to assault rifles (to even consider using it as a bottle opener) - i.e. soldiers are an edge case. Secondly, civilians who have direct access to bottle openers don't even need assault rifles - i.e. most people don't need edge-case solutions.

In the real world, when people want a hammer, they buy a hammer. They don't use shovels for hammering, unless they're forced to use one, or have no other option.

In the programming world all popular programming languages are virtually free. Programmers can choose and select between them. Modifying a language just so that it can do every specific thing (rather than the few things it is good at, or which its ecosystem is good at) is architecturally poor language design. And an excellent way to mess up the language - e.g. see PHP.

A tool should not need to accommodate to the whims and needs of every user. To use your analogy, if the shovel users have easy access to hammers, then they can grab the hammers when they need it, not force shovels into hammers.

To do otherwise is a stupid choice on the part of users, and is in no way a weakness of the design/utility of the language/tool itself.

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

#115

Post by locotower »

nullcat wrote: post #32
masklinn wrote: 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…

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.

I would say it's faster generally but not definitively.

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

#116

Post by locotower »

tracker1 wrote: post #103
nullcat wrote: post #26

Earlier quoted context omitted.

Regardless node IS definitively one of the fastest interpreted platforms around. It is well known that it is faster than python. Python wins in other areas, including being a much much better designed language.

Probably comes from V8 (JS engine in node), likely being the most heavily optimized language runtime engine ever made.

Yeah, it's definitely because of that.

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

#117

Post by killsgnadfamily »

tracker1 wrote: post #103
nullcat wrote: post #26

Earlier quoted context omitted.

Regardless node IS definitively one of the fastest interpreted platforms around. It is well known that it is faster than python. Python wins in other areas, including being a much much better designed language.

Probably comes from V8 (JS engine in node), likely being the most heavily optimized language runtime engine ever made.

Agreed. They have some of the smartest people working on that.

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

#118

Post by d0mine »

ralusek wrote: post #108
d0mine wrote: post #16

Earlier quoted context omitted.

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

They're fundamentally stored as and operated on in different ways. A BigInt does suddenly become a BigInt when in excess of MAX_SAFE_INTEGER, it's a BigInt even with a value of 1n.

fib(35) is much much smaller than the safe max that is the whole point of my comment

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

#119

Post by maxmaio »

contravariant wrote: post #94
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.

I'm having trouble coming up with this approach on my own. could you share it please?
Post reply on HN