3 ms·

Is Javascript significantly slower? It is extremely common in the real world and so a lot of effort has gone into optimizing it - v8 is very good. Yes C and

by bluGill 10mo ago

Is Javascript significantly slower? It is extremely common in the real world and so a lot of effort has gone into optimizing it - v8 is very good. Yes C and Rust enable more optimizations: they will be slightly faster, but javascript has had a lot of effort put into making it run fast.

sgeisenh 10mo ago
Yes, for most real-world examples JavaScript is significantly slower; JIT isn’t free and can be very sensitive to small code changes, you also have to consider the garbage collector. Speed is also not the only metric, Rust and C enable much better control over memory usage. In general, it is easier to write a memory-efficient program in Rust or C than it is in JS.
kibwen 10mo ago
Yes. V8 (and other Javascript JIT engines) are very good, with a lot of effort put into them by talented engineers. But there's a floor on performance imposed by the language's own semantics. Of course, if your program is I/O bound rather than CPU bound (especially at network-scale latencies), this may never be noticeable. But a Javascript program will use significantly more CPU, significantly more memory, and both CPU and memory usage will be significantly more variable and less predictable than a program written in C or Rust.
- sfink 10mo ago
  It's complicated, though mostly that complication doesn't change the overall conclusion. Much of the language's semantics can be boiled away before JIT compilation, because that flexibility isn't in use at that time, which can be proven by a quick check before entering the hot code. (Or in the extreme, the JIT code doesn't check it at all, and the runtime invalidates that code lazily when an operation is performed that violates those preconditions.) Which thwarts people who do simple-minded comparisons of "what language is fastest at `for (i = 0; i < 10000000; i++) x += 7`?", because the runtime is entirely dominated by the hot loop, and the machine code for the hot loop is identical across all languages tested. Still: you have to spend time JIT compiling. You have to do some dynamic checks in all but the innermost hot code. You have to materialize data in memory, even if just as a fallback, and you have to garbage collect periodically. So I agree with your conclusion, except for perhaps un-nuanced use of the term "performance floor" -- there's really no elevated JS floor, at least not a global one; simple JS can generate the same or nearly the same machine code as equivalent C/C++/Rust, will use no more memory, and will never GC. But that floor only applies to a small subset of code (which can be the bulk of the runtime!), and the higher floor does kick in for everything else. So generally speaking, JS can only "be as fast" as non-managed languages for simple programs. (I'll ignore the situations where the JIT can depend on stricter constraints at runtime than AOT-compiled languages, because I've never seen a real-world situation where it helps enough to counterbalance everything else.)

by bluGill 10mo ago

sgeisenh 10mo ago

Yes, for most real-world examples JavaScript is significantly slower; JIT isn’t free and can be very sensitive to small code changes, you also have to consider the garbage collector. Speed is also not the only metric, Rust and C enable much better control over memory usage. In general, it is easier to write a memory-efficient program in Rust or C than it is in JS.

kibwen 10mo ago

Yes. V8 (and other Javascript JIT engines) are very good, with a lot of effort put into them by talented engineers. But there's a floor on performance imposed by the language's own semantics. Of course, if your program is I/O bound rather than CPU bound (especially at network-scale latencies), this may never be noticeable. But a Javascript program will use significantly more CPU, significantly more memory, and both CPU and memory usage will be significantly more variable and less predictable than a program written in C or Rust.

sfink 10mo ago
It's complicated, though mostly that complication doesn't change the overall conclusion. Much of the language's semantics can be boiled away before JIT compilation, because that flexibility isn't in use at that time, which can be proven by a quick check before entering the hot code. (Or in the extreme, the JIT code doesn't check it at all, and the runtime invalidates that code lazily when an operation is performed that violates those preconditions.) Which thwarts people who do simple-minded comparisons of "what language is fastest at `for (i = 0; i < 10000000; i++) x += 7`?", because the runtime is entirely dominated by the hot loop, and the machine code for the hot loop is identical across all languages tested. Still: you have to spend time JIT compiling. You have to do some dynamic checks in all but the innermost hot code. You have to materialize data in memory, even if just as a fallback, and you have to garbage collect periodically. So I agree with your conclusion, except for perhaps un-nuanced use of the term "performance floor" -- there's really no elevated JS floor, at least not a global one; simple JS can generate the same or nearly the same machine code as equivalent C/C++/Rust, will use no more memory, and will never GC. But that floor only applies to a small subset of code (which can be the bulk of the runtime!), and the higher floor does kick in for everything else. So generally speaking, JS can only "be as fast" as non-managed languages for simple programs. (I'll ignore the situations where the JIT can depend on stricter constraints at runtime than AOT-compiled languages, because I've never seen a real-world situation where it helps enough to counterbalance everything else.)