4 ms·

Is the performance difference of Python and Javascript due to the language or due to the runtime? If one would compile both, the Python version and the Javascr

by mg 4y ago

Is the performance difference of Python and Javascript due to the language or due to the runtime? If one would compile both, the Python version and the Javascript version, to WebAssembly and execute that, how would the performance differ then?

edflsafoiewq 4y ago
Python and JS are basically the same language in terms of semantics.
- _ZeD_ 4y ago
  well, as long as both of them are descendant of modula 2 :) but no. while both languages share some similarities (dynamically typed, some form of "objects" and "classes") there are a lot of differences, both at "language level" and at "implementation level"
  - edflsafoiewq 4y ago
    What are some important differences do you think?
    - exebook 4y ago
      Lexical scope and first class functions in JavaScript as a descendant from Lisp.
- dragonwriter 4y ago
  > Python and JS are basically the same language in terms of semantics. Python is dynamic class-based OO with multiple inheritance. JS is dynamic prototypical OO, though it has recently added convenience syntax implementing single-inheritance class-based OO on top of it. They are not the same.
  - edflsafoiewq 4y ago
    It's still redirecting to another object at runtime in both cases. The details are obviously not exactly identical but there's no great difference in the object model just because one is called a "class" and one is called a "prototype".
  - Symmetry 4y ago
    Python also has much stronger typing in to converting types of things willy nilly without being instructed to.
brrrrrm 4y ago
It's due to the runtime. JavaScript has a runtime that updates as it executes. It notices a loop is being run frequently and then compiles a new version of the loop that runs faster. Python doesn't have this functionality. WebAssembly is for running things in the browser and would slow everything down (Python, JS, C++). The tests in the post are run natively (on my command line).
- deleted 4y ago
  [deleted]
- cogman10 4y ago
  Python does have this functionality, but it's hamstrung by the implementation. Javascript is, for the most part, completely sandboxed and separate. Which means the JIT for Javascript is totally free to do neat things like move an object from one region of memory to another. CPython, on the other hand, has to care about things like "was this object created in C? Is it pinned to that memory location? Does this method end up delegating to C?" And you see that in the complexity it takes to introduce native methods in both. Moving and using data from JS to Webassembly is a PITA. Accessing data in a Python object from c ( and vice versa) is trivial. That triviality is what gets in the way of JIT optimizations.
  - brrrrrm 4y ago
    I don't buy this argument. WebAssembly is a vastly different beast than trivial C extensions (since WASM is a browser thing). JavaScript has both and is still much faster. Bun (the runtime I used for the post), has a native C interface that's far simpler to use than Python (even with pybind/nanobind): https://github.com/oven-sh/bun#bunffi-foreign-functions-interface https://github.com/oven-sh/bun#bunffi-foreign-functions-inte... Deno (a v8-based runtime) has the same thing: https://deno.land/manual@v1.25.4/runtime/ffi_api https://deno.land/manual@v1.25.4/runtime/ffi_api These use the standard C-ABI directly without requiring headers (unlike Python). Node.js standardized a more Python-like C API called Node-API: https://nodejs.org/api/n-api.html https://nodejs.org/api/n-api.html I believe Python can continue to add performance and is not hamstrung by the implementation.
kzrdude 4y ago
It's both. Language semantics make it hard to optimize Python, even for the runtime / even for a JIT.
- somekyle 4y ago
  An underrated factor in this conversation is implementation effort. Javascript is arguably the most widely run interpreted language in the world. Pre-Chrome, JS was uniformly rather slow, but Google was betting on webapps being good and usable, so they brought on some top-tier compilation/VM talent to build V8. As fast Javascript existed, it made it possible to do more natively in the browser, and other browser vendors joined in an arms race there. Tons of effort overall, tons of money and time from top-tier experts. There was no equivalent competition between major organizations to make Python fast. Folks have tried, but not on the same scale. Yes, factors like language design and existing ecosystems entanglements played a role here, but if Python had the investment in performance Javascript had (financial and expert attention), it'd be dramatically faster today (though it may have required a fork or similar, depending on how tied to simplicity Guido was feeling). To be clear, I'm not saying nobody tried to make Python faster, or that Python devs don't know what they're doing. I know very well both of those things aren't true. But, the kind of sophistication required to make Python fast in absolute terms is very hard to build and maintain, and for various reasons nobody who has found Python to be too slow has found "invest in a bunch of person-years of VM engineer attention dedicated to performance work" to be their best path.
  - kzrdude 4y ago
    I think you are right, but there are signs of great effort - pypy, unladen swallow, and many other projects that still exist or do not.
williamstein 4y ago
The WebAssembly version of this exact test takes about twice as long as running natively. I just happened to do exactly this benchmark a few minutes ago: Python 3.11.0 native: 0m43.755s Python 3.11.0 WebAssembly (on node.js): 1m31.305s (about 2.1x as long). For what it is worth, I also maintain a Python --> Javascript transpiler (https://www.npmjs.com/package/pylang https://www.npmjs.com/package/pylang) and I tried it on exactly this benchmark (with some very minor changes): PyLang: 0m19.386s (on node.js) about half as long as Python 3.11.0 native The article uses bun, which uses Safari's JS runtime, which sometimes has significantly better performance than node.js for these sorts of benchmarks (especially for Webassembly), in my experience. These tests were all on an M1 Macbook Pro.
outworlder 4y ago
> Is the performance difference of Python and Javascript due to the language or due to the runtime? It's almost always the runtime. Unless the language spec makes it particularly difficult to implement a feature in a way that's performant while still respecting the spec. Which is why the discussion on which languages are "faster" is seldom productive. Languages are not fast or slow by themselves. And, even when they are on average, implementing stuff on Assembly is no guarantee of speed. Quite often, higher level abstractions lead to optimizations that are difficult to replicate if one is operating at a lower level. As a very trivial example, consider short circuit evaluation. It's something that you explicitly have to code in assembly, but most languages have implemented out of the box. Or garbage collection - allocating and deallocating memory on demand is memory efficient, but it's not necessarily what you want to do for performance. In many cases, deferring garbage collection allows for often-accessed memory to be retained, where as a C implementation would be constantly allocating and freeing. Fixing that requires programmer effort. What I think matters the most is the ability of a language (+runtime) to access lower layers when needed (ASM blocks in C, FFI in Python).
- DeathArrow 4y ago
  >And, even when they are on average, implementing stuff on Assembly is no guarantee of speed. Quite often, higher level abstractions lead to optimizations that are difficult to replicate if one is operating at a lower level. When browsing Code Golf, most often than not, the fastest implementation is in assembler. And sometimes it can be 2x - 4x faster than next fastest implementation which usually is C++.
- gpderetta 4y ago
  While with enough trust even pigs can fly (witness the heroic efforts to make JS fast), some languages are indeed inherently faster than others either because the semantics are such that they are easier to translate to an actual machine efficiently or there is less abstraction between the language and the machine.

by mg 4y ago

edflsafoiewq 4y ago

Python and JS are basically the same language in terms of semantics.

_ZeD_ 4y ago
well, as long as both of them are descendant of modula 2 :) but no. while both languages share some similarities (dynamically typed, some form of "objects" and "classes") there are a lot of differences, both at "language level" and at "implementation level"
- edflsafoiewq 4y ago
  What are some important differences do you think?
  - exebook 4y ago
    Lexical scope and first class functions in JavaScript as a descendant from Lisp.
dragonwriter 4y ago
> Python and JS are basically the same language in terms of semantics. Python is dynamic class-based OO with multiple inheritance. JS is dynamic prototypical OO, though it has recently added convenience syntax implementing single-inheritance class-based OO on top of it. They are not the same.
- edflsafoiewq 4y ago
  It's still redirecting to another object at runtime in both cases. The details are obviously not exactly identical but there's no great difference in the object model just because one is called a "class" and one is called a "prototype".
- Symmetry 4y ago
  Python also has much stronger typing in to converting types of things willy nilly without being instructed to.

brrrrrm 4y ago

It's due to the runtime. JavaScript has a runtime that updates as it executes. It notices a loop is being run frequently and then compiles a new version of the loop that runs faster. Python doesn't have this functionality. WebAssembly is for running things in the browser and would slow everything down (Python, JS, C++). The tests in the post are run natively (on my command line).

deleted 4y ago
[deleted]
cogman10 4y ago
Python does have this functionality, but it's hamstrung by the implementation. Javascript is, for the most part, completely sandboxed and separate. Which means the JIT for Javascript is totally free to do neat things like move an object from one region of memory to another. CPython, on the other hand, has to care about things like "was this object created in C? Is it pinned to that memory location? Does this method end up delegating to C?" And you see that in the complexity it takes to introduce native methods in both. Moving and using data from JS to Webassembly is a PITA. Accessing data in a Python object from c ( and vice versa) is trivial. That triviality is what gets in the way of JIT optimizations.
- brrrrrm 4y ago
  I don't buy this argument. WebAssembly is a vastly different beast than trivial C extensions (since WASM is a browser thing). JavaScript has both and is still much faster. Bun (the runtime I used for the post), has a native C interface that's far simpler to use than Python (even with pybind/nanobind): https://github.com/oven-sh/bun#bunffi-foreign-functions-interface https://github.com/oven-sh/bun#bunffi-foreign-functions-inte... Deno (a v8-based runtime) has the same thing: https://deno.land/manual@v1.25.4/runtime/ffi_api https://deno.land/manual@v1.25.4/runtime/ffi_api These use the standard C-ABI directly without requiring headers (unlike Python). Node.js standardized a more Python-like C API called Node-API: https://nodejs.org/api/n-api.html https://nodejs.org/api/n-api.html I believe Python can continue to add performance and is not hamstrung by the implementation.

kzrdude 4y ago

It's both. Language semantics make it hard to optimize Python, even for the runtime / even for a JIT.

somekyle 4y ago
An underrated factor in this conversation is implementation effort. Javascript is arguably the most widely run interpreted language in the world. Pre-Chrome, JS was uniformly rather slow, but Google was betting on webapps being good and usable, so they brought on some top-tier compilation/VM talent to build V8. As fast Javascript existed, it made it possible to do more natively in the browser, and other browser vendors joined in an arms race there. Tons of effort overall, tons of money and time from top-tier experts. There was no equivalent competition between major organizations to make Python fast. Folks have tried, but not on the same scale. Yes, factors like language design and existing ecosystems entanglements played a role here, but if Python had the investment in performance Javascript had (financial and expert attention), it'd be dramatically faster today (though it may have required a fork or similar, depending on how tied to simplicity Guido was feeling). To be clear, I'm not saying nobody tried to make Python faster, or that Python devs don't know what they're doing. I know very well both of those things aren't true. But, the kind of sophistication required to make Python fast in absolute terms is very hard to build and maintain, and for various reasons nobody who has found Python to be too slow has found "invest in a bunch of person-years of VM engineer attention dedicated to performance work" to be their best path.
- kzrdude 4y ago
  I think you are right, but there are signs of great effort - pypy, unladen swallow, and many other projects that still exist or do not.

williamstein 4y ago

The WebAssembly version of this exact test takes about twice as long as running natively. I just happened to do exactly this benchmark a few minutes ago: Python 3.11.0 native: 0m43.755s Python 3.11.0 WebAssembly (on node.js): 1m31.305s (about 2.1x as long). For what it is worth, I also maintain a Python --> Javascript transpiler (https://www.npmjs.com/package/pylang https://www.npmjs.com/package/pylang) and I tried it on exactly this benchmark (with some very minor changes): PyLang: 0m19.386s (on node.js) about half as long as Python 3.11.0 native The article uses bun, which uses Safari's JS runtime, which sometimes has significantly better performance than node.js for these sorts of benchmarks (especially for Webassembly), in my experience. These tests were all on an M1 Macbook Pro.

outworlder 4y ago

> Is the performance difference of Python and Javascript due to the language or due to the runtime? It's almost always the runtime. Unless the language spec makes it particularly difficult to implement a feature in a way that's performant while still respecting the spec. Which is why the discussion on which languages are "faster" is seldom productive. Languages are not fast or slow by themselves. And, even when they are on average, implementing stuff on Assembly is no guarantee of speed. Quite often, higher level abstractions lead to optimizations that are difficult to replicate if one is operating at a lower level. As a very trivial example, consider short circuit evaluation. It's something that you explicitly have to code in assembly, but most languages have implemented out of the box. Or garbage collection - allocating and deallocating memory on demand is memory efficient, but it's not necessarily what you want to do for performance. In many cases, deferring garbage collection allows for often-accessed memory to be retained, where as a C implementation would be constantly allocating and freeing. Fixing that requires programmer effort. What I think matters the most is the ability of a language (+runtime) to access lower layers when needed (ASM blocks in C, FFI in Python).

DeathArrow 4y ago
>And, even when they are on average, implementing stuff on Assembly is no guarantee of speed. Quite often, higher level abstractions lead to optimizations that are difficult to replicate if one is operating at a lower level. When browsing Code Golf, most often than not, the fastest implementation is in assembler. And sometimes it can be 2x - 4x faster than next fastest implementation which usually is C++.
gpderetta 4y ago
While with enough trust even pigs can fly (witness the heroic efforts to make JS fast), some languages are indeed inherently faster than others either because the semantics are such that they are easier to translate to an actual machine efficiently or there is less abstraction between the language and the machine.