
A typical Node.js app is orders of magnitude faster than python3 app - el_programmador
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-python3.html
======
__d
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)

~~~
igouy
> I'd like to see

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

[https://salsa.debian.org/benchmarksgame-
team/benchmarksgame](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?

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

~~~
igouy
> …it’d make more sense …

[https://benchmarksgame-
team.pages.debian.net/benchmarksgame/...](https://benchmarksgame-
team.pages.debian.net/benchmarksgame/sometimes-people-just-make-up-
stuff.html#maintenance-burden)

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?

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

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

