4 ms·

This post is extremely V8-centric. For example it uses terminology like “deopts” which means nothing in JavaScriptCore (we distinguish between exits, invalidati

This post is extremely V8-centric. For example it uses terminology like “deopts” which means nothing in JavaScriptCore (we distinguish between exits, invalidations, jettisons, and recompiles). The post also assumes that there is only one JIT (JSC has multiple). And that’s where you’ve lost me. Not sure how you expose anything about how the JIT is operating without introducing a compat shitshow since JIT means different things in different implementations. If you really want to know that something gets compiled with the types you want, use a statically typed and ahead of time compiled language. If you have to use a JIT but you find that it doesn’t do what you like then remember that it’s meant to be stochastic. The VM is just trying to win in the average. Which functions get compiled and with what type information can vary from run to run. Probably the best thing that could happen is that developer tools tell you more about what the JIT is doing. But even that’s hard. There are some specifics that I disagree with: - I don’t think all JIT architects for JS claim that the perf is about competing with C for numerical code. I don’t explain it that way. I would say: JITs are about doing the best job you can do under the circumstances. They can make JS run 4x faster than an interpreter if things really go well. “Between Python and Java” is a good way to put it and that’s exactly what I would expect. So if that’s your experience then great! The JIT worked as expected. - It’s usually foolish to want your code compiled sooner. Compilation delay is about establishing confidence in profiling. I’m pretty sure we’d JIT much sooner if it wasn’t for the fact that it would make the EV of our speculation go negative. TL;DR. the JIT can’t unfuck up JavaScript.

csande17 7y ago
The post is likely V8-centric because it's discussing server-side JavaScript. As far as I know, pretty much everyone uses V8 for server-side JS because that's what Node is based on. And compatibility seems to be much less of an issue there as well, at least if all the "dropped support for Node version X" changelogs I read are any indication. Not to say server-side JavaScript is necessarily a good idea. But if people are determined to make it work, I could see these sorts of changes happening that wouldn't make sense in a web browser.
deleted 7y ago
[deleted]
bjourne 7y ago
> Probably the best thing that could happen is that developer tools tell you more about what the JIT is doing. But even that’s hard. Why? You have the exact same problem when writing SQL code but there you have lots of powerful introspection tools to make it easier to control performance. You can also use indices and hints to nudge the RDBMS into executing queries in the most optimal way. PyPy for example has a lot of support for introspection.
- pizlonator 7y ago
  Because JS JITs aren’t deterministic. Just starting the profiling or introspection tool could change internal behavior. The nondeterminism can come from lots of places. In JSC it’s that the JIT polls the heap for some of its profiling and it profiles concurrently. So OS scheduling decisions affect what types the JIT sees.
  - saagarjha 7y ago
    > Because JS JITs aren’t deterministic. Just starting the profiling or introspection tool could change internal behavior. All all JavaScript JITs this way?
    - pizlonator 7y ago
      All the good ones. In all seriousness, I think I heard that FF doesn’t profile concurrently. Maybe that’s one of the reasons why they’re so slow.
  - bjourne 7y ago
    Performance in general is non-deterministic in a multi-tasking os because you have multiple processes competing for cpu time. My point is that there is nothing inherent to Javascript VMs that makes them harder to control or analyze. Runtimes for other dynamic languages and database engines shows that proper tooling makes it much easier for developers to optimize for performance.
    - 7y ago

csande17 7y ago

The post is likely V8-centric because it's discussing server-side JavaScript. As far as I know, pretty much everyone uses V8 for server-side JS because that's what Node is based on. And compatibility seems to be much less of an issue there as well, at least if all the "dropped support for Node version X" changelogs I read are any indication. Not to say server-side JavaScript is necessarily a good idea. But if people are determined to make it work, I could see these sorts of changes happening that wouldn't make sense in a web browser.

deleted 7y ago

[deleted]

bjourne 7y ago

> Probably the best thing that could happen is that developer tools tell you more about what the JIT is doing. But even that’s hard. Why? You have the exact same problem when writing SQL code but there you have lots of powerful introspection tools to make it easier to control performance. You can also use indices and hints to nudge the RDBMS into executing queries in the most optimal way. PyPy for example has a lot of support for introspection.

pizlonator 7y ago
Because JS JITs aren’t deterministic. Just starting the profiling or introspection tool could change internal behavior. The nondeterminism can come from lots of places. In JSC it’s that the JIT polls the heap for some of its profiling and it profiles concurrently. So OS scheduling decisions affect what types the JIT sees.
- saagarjha 7y ago
  > Because JS JITs aren’t deterministic. Just starting the profiling or introspection tool could change internal behavior. All all JavaScript JITs this way?
  - pizlonator 7y ago
    All the good ones. In all seriousness, I think I heard that FF doesn’t profile concurrently. Maybe that’s one of the reasons why they’re so slow.
- bjourne 7y ago
  Performance in general is non-deterministic in a multi-tasking os because you have multiple processes competing for cpu time. My point is that there is nothing inherent to Javascript VMs that makes them harder to control or analyze. Runtimes for other dynamic languages and database engines shows that proper tooling makes it much easier for developers to optimize for performance.
  - 7y ago