A typical Node.js app is orders of magnitude faster than python3 app | Hacker News Reader

A typical Node.js app is orders of magnitude faster than python3 app

benchmarksgame-team.pages.debian.net

I guess I'd like to see results using Pypy as well as CPython, since comparing an interpreter with the node.js runtime seems it only proves an obvious point: a JIT will usually outperform an interpreter.

(Except where it doesn't, as in some of these cases)

But doesn't python3 now generate bytecode (.pyc files or __pycache__) too? Is there a fundamentally large difference between these and the .class java files or the node's equivalent?

The difference is what happens after the bytecode files are loaded.

> I'd like to see

Here's the source code for all the programs, go measure :-)

https://salsa.debian.org/benchmarksgame-team/benchmarksgame

> an obvious point

No:

a) you're just assuming that everyone has seen what you personally have seen

b) as you noticed - except where it doesn't - so what's the "obvious" explanation?

Well, sure I could go do that measurement myself, but it’d make more sense to have the results in one place?

A) my assumption is more that people understand the difference between a pure interpreter and a JIT. Clearly there’s value in showing the results regardless, but there’d be more value in comparing with a JITed Python runtime as well?

B) The obvious bit is that a JIT such as V8 will generate, compile, and use native code segments vs CPython’s interpreter.

There’s plenty of use in the current results, but it just seemed to me they could be fairly easily made more useful re-running with Pypy in the same environment.

> …it’d make more sense …

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Not if you're the person who would have to do the work ;-)

> …my assumption is more that people understand…

Bad assumption :-)

> The obvious bit is that…

The question was — what's the "obvious" explanation for those cases where Node is not faster?

> Not if you're the person who would have to do the work ;-)

I think it'd still make sense, but I understand it might not be something that you'd consider worth doing :-)

> Bad assumption :-)

I'm kinda prepared to live with that.

> The question was — what's the "obvious" explanation for those cases where Node is not faster?

I don't think there is an obvious explanation for those cases. They're the surprising, and interesting, results. The cases where a JIT beats an interpreter are to be expected.

But ok ... I can bite. In general, I'd expect Node to thrash Python on anything that doesn't fall through to a C implementation.

The regex results suggest that the bulk of the performance comes from the underlying regex implementation, so the relatively small difference there is probably just Python's string handling, maybe some startup time, etc.

The binary trees result is curious, but without looking at the code, hard to guess.

k-nucleotide shows a lot of memory usage in Node (vs Python), which might contribute to the closeness of the results? JIT not winning much again. is Python using some C module here?

reverse complement has similar time, memory usage, and CPU loading. not sure what the content is, but the JIT's clearly not doing much here. similar to the last one.

pidigits shows a clear win for Python. Pretty odd. I'd likely look into the implementations of this one before going much deeper.

I'm not sure I've intrigued myself enough to actually attempt to duplicate your setup, but it is winter here ...

> I'm kinda prepared to live with that [bad assumption].

Seems like el_programmador's follow-up question shows how bad.

> …a clear win for Python…

> …fall through to a C implementation…

The obvious explanation.

> …without looking at the code … likely look into the implementations…

The source code is one-click from the page el_programmador linked.

Reply on news.ycombinator.com