4 ms·

If we really care about performance, then this split between the runtime and user code is not ideal. What we should be trying to do is bake the user code into t

If we really care about performance, then this split between the runtime and user code is not ideal. What we should be trying to do is bake the user code into the runtime and apply total program optimization. This can be done today with C, C++ and Rust. However, in principle JavaScript code could be transpiled to Zig and then baked into Deno.

brrrrrm 4y ago
JITs (as those found in V8, JSC, SpiderMonkey) can theoretically compile better code than static compilation approaches like C, C++, and Rust. It's because the runtime can collect information about what is being run and then generate code accordingly.
- yencabulator 4y ago
  https://arxiv.org/abs/1602.00602 https://arxiv.org/abs/1602.00602 is a good exploration of why this just doesn't work out, and at best tends to lead to weird stuttering performance.
- whatshisface 4y ago
  Static compilers can also sometimes do that, it's called profile-guided optimization.
- emtel 4y ago
  This is true in some situations, but I think is mostly a just-so story told about JITed languages. Here's the problems: 1) Often, you have lots of code that only runs once (e.g. UI initialization), or runs rarely (click handlers). By the time the JIT has had an opportunity to observe this code and optimize it, it may be too late. 2) The dynamic nature of JS means that making your code JIT-friendly requires deep knowledge of what language features to avoid. 3) Performance isn't only driven by having the tightest possible machine code. Memory layout is often more important on modern processors. Indirection causes cache misses, and JS objects contain far more indirection than equivalent structs defined in C/C++/Rust. Further, in Javascript you can't really create cache-friendly collections of objects like vectors, BTreeMaps, etc.
- adwn 4y ago
  The "JITed languages can be faster than natively compiled ones" meme has been making the rounds at least since Java gained JIT support. It never worked out that way (except for niche cases), for several reasons: 1) Gathering information at runtime competes with the actual program for resources. 2) Optimizing at runtime competes with the actual program for resources. 3) Most importantly, JITed languages tend to be pointer-heavy and full of indirections, and there's not much a JIT compiler can do about that.
- diroussel 4y ago
  This is true. But in practice they take a long time to warm up, may or may not get faster, and in general don’t attempt total program optimisation. As some parts of the node standard lib is native code and can’t be optimised at runtime.

brrrrrm 4y ago

JITs (as those found in V8, JSC, SpiderMonkey) can theoretically compile better code than static compilation approaches like C, C++, and Rust. It's because the runtime can collect information about what is being run and then generate code accordingly.

yencabulator 4y ago
https://arxiv.org/abs/1602.00602 https://arxiv.org/abs/1602.00602 is a good exploration of why this just doesn't work out, and at best tends to lead to weird stuttering performance.
whatshisface 4y ago
Static compilers can also sometimes do that, it's called profile-guided optimization.
emtel 4y ago
This is true in some situations, but I think is mostly a just-so story told about JITed languages. Here's the problems: 1) Often, you have lots of code that only runs once (e.g. UI initialization), or runs rarely (click handlers). By the time the JIT has had an opportunity to observe this code and optimize it, it may be too late. 2) The dynamic nature of JS means that making your code JIT-friendly requires deep knowledge of what language features to avoid. 3) Performance isn't only driven by having the tightest possible machine code. Memory layout is often more important on modern processors. Indirection causes cache misses, and JS objects contain far more indirection than equivalent structs defined in C/C++/Rust. Further, in Javascript you can't really create cache-friendly collections of objects like vectors, BTreeMaps, etc.
adwn 4y ago
The "JITed languages can be faster than natively compiled ones" meme has been making the rounds at least since Java gained JIT support. It never worked out that way (except for niche cases), for several reasons: 1) Gathering information at runtime competes with the actual program for resources. 2) Optimizing at runtime competes with the actual program for resources. 3) Most importantly, JITed languages tend to be pointer-heavy and full of indirections, and there's not much a JIT compiler can do about that.
diroussel 4y ago
This is true. But in practice they take a long time to warm up, may or may not get faster, and in general don’t attempt total program optimisation. As some parts of the node standard lib is native code and can’t be optimised at runtime.