3 ms·

I'm curious if there's more to nodejs's relatively high performance than just Google's time/money put into v8. Would an equivalent amount of effort on Python h

by tyingq 2y ago

I'm curious if there's more to nodejs's relatively high performance than just Google's time/money put into v8. Would an equivalent amount of effort on Python have ended in similar performance? Or do python things like "everything's an object", etc, set a hard ceiling?

crabbone 2y ago
JavaScript has, basically, no library to speak of. The language is very small. Python comes with a lot of stuff, and that stuff is of very variable quality and performance. So, if you are trying to benchmark two languages against each other, it's just not going to work well because for the vast majority of Python there's simply nothing in JavaScript that does that.
- crabbone 2y ago
  Now, I often get downvoted because I (wrongly) chose a hill to die on... but this one? Come on guys!? JavaScript is described in a standard that's like 50 pages PDF, most of which isn't code... Python has hundreds of modules in the standard library. It's humongous compared to JavaScript. I don't understand why this is such a controversial idea...
  - hifromwork 2y ago
    I didn't downvote you (I'm just reading this thread for the first time), but I don't get your original argument. Usually benchmarking two languages means either: * microbenchmarks comparing speed of doing stupid things (like adding 10000 integers or sorting a list with bubblesort 1000 times) * 'real world'-ish benchmarks comparing idiomatic solutions in two languages doing the same thing In both cases it doesn't matter (much) how big a standard library is. If you want to compare two languages doing something complex, you need to have -standard or not- implementation of that something for both languages. But maybe I (and possibly others) have missed your point?
    - crabbone 2y ago
      Well, people who write such benchmarks have no business writing benchmarks, and the comments to such comparison would usually say as much. Such benchmarks don't compare anything in a meaningful way, and, in the second case, don't even compare what they claim to compare (you don't compare the languages if you run some third-party code on top of it, which has nothing to do with how the language itself is implemented). These "benchmarks" just score some holly-war points for people who either irrationally like, or irrationally hate a particular language...
      - animuchan 2y ago
        So we're in a "no true Scotsman" situation then, where no benchmark is ever useful. I kind of disagree on the meaningfulness of microbenchmarks, they give a feel for the performance, even if it's not a perfectly useful apples-to-apples comparison. Like, if decoding a large JSON takes 3 milliseconds in one language and 2 minutes in another, that's signaling that the second language is a worse fit for certain projects. Even if the benchmark isn't super rigorous.
        crabbone 2y ago
        How did you get this impression? No, we are not in a true Scotsman situation. In order to establish that some language is faster than the other, you can devise a convincing metric. It will have to state what are the aspects that you are going to take into account, what are you baseline assumptions about measuring speed. Those using your experiment then will be able to practically use your results because they will be able to interpret your meaning of speed of the language. The test in OP doesn't give anything like that. It ignores a lot of common testing practices by failing to control for many obvious confounds, by failing to provide any kind of sensible explanation of what is meant by the speed of the language, by using unreliable measuring techniques. It's just a hands-down awful way to test anything by the standards of people in the field of performance testing. To further illustrate my point. Suppose you trust OP when they say that Python and JavaScript are roughly similar when it comes to the speed of calculating Fibonacci numbers. You then take a 16-cores server and run 16 processes of Python program calculating Fibonacci numbers and in another instance you take the same server and run 16 JavaScript process doing the same... only to discover that, eg. JavaScript now does 16 times better than Python (because Python decided to run all programs on the same core). Note, I'm not saying that that's how Python actually works. All I'm saying is that the author doesn't control for this very obvious feature of contemporary hardware and never explicitly acknowledges any baseline assumptions about how the program is supposed to be executed. This is bad testing practice, intentionally or not it can be used to score "political" points, to promote a particular program over another.
  - gchamonlive 2y ago
    I dislike the habit we see here of downvoting without commenting the reason why the comment is being downvoted. We can only guess, but I believe it's because even though that is true, that python packs a lot more in its library than js, therefore more batteries, more time spent including those batteries and less time spent optimizing the interpreter, but standard benchmarks do away with all of that and focus on simple problems, like adding two numbers, to see how each language behaves.
sltkr 2y ago
Have you looked at the PyPy benchmarks in the article? Broadly speaking, PyPy is to Python as v8 is to JavaScript.
- tyingq 2y ago
  Yes, though that's Fibonacci, etc. I assume V8 still has a large edge against PyPy for a lot of real world applications.
animuchan 2y ago
While v8 is without a doubt a very impactful project, there are JS runtimes that prioritize speed, and they aren't v8-based. One example is Bun, which is I think based on JavaScriptCore, the Safari's JS implementation. So I don't think it's attributable to Google's implementation.
- tyingq 2y ago
  Ah, though I don't know what relative amount of similar time/money Apple dumped into that engine.
lou1306 2y ago
I am by no means an expert in CPython/V8 internals, but arguably Python is way more dynamic (e.g., dunder methods), performs way more runtime checks (whereas JS will happily keep on trucking if, say, you add a string to an integer), and its design makes it very hard to infer which value inhabits a variable at a given point in time (which you would need in order to apply optimizations to the bytecode). This kind of flexibility cannot come for free.
- Qem 2y ago
  Smalltalk and lisp are arguably even more dynamic and yet we have examples of faster runtimes for both.
  - igouy 2y ago
    Except Python is as fast as C when it is C and Python text functions quickly become C functions. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/pharo-python.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

by tyingq 2y ago

crabbone 2y ago

JavaScript has, basically, no library to speak of. The language is very small. Python comes with a lot of stuff, and that stuff is of very variable quality and performance. So, if you are trying to benchmark two languages against each other, it's just not going to work well because for the vast majority of Python there's simply nothing in JavaScript that does that.

crabbone 2y ago
Now, I often get downvoted because I (wrongly) chose a hill to die on... but this one? Come on guys!? JavaScript is described in a standard that's like 50 pages PDF, most of which isn't code... Python has hundreds of modules in the standard library. It's humongous compared to JavaScript. I don't understand why this is such a controversial idea...
- hifromwork 2y ago
  I didn't downvote you (I'm just reading this thread for the first time), but I don't get your original argument. Usually benchmarking two languages means either: * microbenchmarks comparing speed of doing stupid things (like adding 10000 integers or sorting a list with bubblesort 1000 times) * 'real world'-ish benchmarks comparing idiomatic solutions in two languages doing the same thing In both cases it doesn't matter (much) how big a standard library is. If you want to compare two languages doing something complex, you need to have -standard or not- implementation of that something for both languages. But maybe I (and possibly others) have missed your point?
  - crabbone 2y ago
    Well, people who write such benchmarks have no business writing benchmarks, and the comments to such comparison would usually say as much. Such benchmarks don't compare anything in a meaningful way, and, in the second case, don't even compare what they claim to compare (you don't compare the languages if you run some third-party code on top of it, which has nothing to do with how the language itself is implemented). These "benchmarks" just score some holly-war points for people who either irrationally like, or irrationally hate a particular language...
    - animuchan 2y ago
      So we're in a "no true Scotsman" situation then, where no benchmark is ever useful. I kind of disagree on the meaningfulness of microbenchmarks, they give a feel for the performance, even if it's not a perfectly useful apples-to-apples comparison. Like, if decoding a large JSON takes 3 milliseconds in one language and 2 minutes in another, that's signaling that the second language is a worse fit for certain projects. Even if the benchmark isn't super rigorous.
      - crabbone 2y ago
        How did you get this impression? No, we are not in a true Scotsman situation. In order to establish that some language is faster than the other, you can devise a convincing metric. It will have to state what are the aspects that you are going to take into account, what are you baseline assumptions about measuring speed. Those using your experiment then will be able to practically use your results because they will be able to interpret your meaning of speed of the language. The test in OP doesn't give anything like that. It ignores a lot of common testing practices by failing to control for many obvious confounds, by failing to provide any kind of sensible explanation of what is meant by the speed of the language, by using unreliable measuring techniques. It's just a hands-down awful way to test anything by the standards of people in the field of performance testing. To further illustrate my point. Suppose you trust OP when they say that Python and JavaScript are roughly similar when it comes to the speed of calculating Fibonacci numbers. You then take a 16-cores server and run 16 processes of Python program calculating Fibonacci numbers and in another instance you take the same server and run 16 JavaScript process doing the same... only to discover that, eg. JavaScript now does 16 times better than Python (because Python decided to run all programs on the same core). Note, I'm not saying that that's how Python actually works. All I'm saying is that the author doesn't control for this very obvious feature of contemporary hardware and never explicitly acknowledges any baseline assumptions about how the program is supposed to be executed. This is bad testing practice, intentionally or not it can be used to score "political" points, to promote a particular program over another.
- gchamonlive 2y ago
  I dislike the habit we see here of downvoting without commenting the reason why the comment is being downvoted. We can only guess, but I believe it's because even though that is true, that python packs a lot more in its library than js, therefore more batteries, more time spent including those batteries and less time spent optimizing the interpreter, but standard benchmarks do away with all of that and focus on simple problems, like adding two numbers, to see how each language behaves.

sltkr 2y ago

Have you looked at the PyPy benchmarks in the article? Broadly speaking, PyPy is to Python as v8 is to JavaScript.

tyingq 2y ago
Yes, though that's Fibonacci, etc. I assume V8 still has a large edge against PyPy for a lot of real world applications.

animuchan 2y ago

While v8 is without a doubt a very impactful project, there are JS runtimes that prioritize speed, and they aren't v8-based. One example is Bun, which is I think based on JavaScriptCore, the Safari's JS implementation. So I don't think it's attributable to Google's implementation.

tyingq 2y ago
Ah, though I don't know what relative amount of similar time/money Apple dumped into that engine.

lou1306 2y ago

I am by no means an expert in CPython/V8 internals, but arguably Python is way more dynamic (e.g., dunder methods), performs way more runtime checks (whereas JS will happily keep on trucking if, say, you add a string to an integer), and its design makes it very hard to infer which value inhabits a variable at a given point in time (which you would need in order to apply optimizations to the bytecode). This kind of flexibility cannot come for free.

Qem 2y ago
Smalltalk and lisp are arguably even more dynamic and yet we have examples of faster runtimes for both.
- igouy 2y ago
  Except Python is as fast as C when it is C and Python text functions quickly become C functions. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/pharo-python.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...