Fun fact -- in V8 this is the only case which requires three token lookahead, to distinguish `<!-foo` meaning "less-than not negative foo" from `<!--` meaning "start of HTML comment". There's a whole rewinding mechanism in the scanner which wouldn't have to exist if not for this syntax.
I'm surprised this doesn't implement any sort of automatic differentiation (like dual numbers) - I guess you can use a separate library for that but it's quite a nice-to-have for optimization.
V8 developer here (who happened to also implement perfect hashing in V8's tokenizer) - perfect hashing is a very common compiler optimisation, and as the sibling comment says, is worth it for the runtime scanner speed improvement. If you do end up adding new keywords (which is ~never for anything that wants to preserve backwards compat), then you just recalculate your perfect hash with gperf or by hand or however.
When scanning the stack, you interpret every word as a potential pointer. Then, you ask your GCs allocator "is this pointer's address in one of your pages?". If it isn't, you're done. If it is, then you check if it's the pointer to the start of an object (there's a bitmap of "is object start" for each word on the page). If this passes too, then you effectively reinterpret cast it to a "GC object" base class which is shared for all GC objects, and call the virtual "trace" function from there.
I appreciate your pragmatism, but it falls apart in the statement "do your own research on market rates". How do you discover those without openness about salaries? You could interview at other companies, but then you'd only find other employers' opinions on what they could pay specifically you, not what they could pay someone else like you.
Though, I don't see any discussion here on failed speculation / deoptimisation, and I do see discussion of disabling individual optimisation passes. I guess the generated optimized code assumes that all the speculative types collected during startup stay stable? This makes sense in a highly controlled environment like a game engine, though it makes the project less amenable for general purpose use (which is fine).
This is very cool. The splitting of logic between startup/warmup and execution is crucial here, to be able to get all that type inference and those speculative optimisations without hitting the limits of static analysis of the JS code. I wonder if the speculative optimisations could be further strengthened by taking advantage of e.g. Typescript type annotations.
Fair point - I was being careful with phrasing because I have a pet peeve about people trying to disprove research with anecdotes, but you're right that this is a somewhat different scenario.
Indeed, supposing that both this research and my anecdote are valid, it'd be a rather unfortunate asymmetry in remote work, a fatigue issue that has no good solution which doesn't require one of the participants to compromise.
Anecdotal, and I don't want it to sound like my example is intended to disprove this research or anyone else's experience, but I personally find it extremely fatiguing if people _don't_ turn on their video.
More specifically, when I'm talking in a meeting or giving a presentation, I find it very helpful to see other people, see their reactions, see whether they laugh at jokes or look confused when I'm bad at explaining things. My nightmare during remote work is giving a presentation to a silent wall of "camera off" icons.
Not that this is very relevant to drones, but I've found over the past ~year that burgers survive being delivered surprisingly well, and the burritos I've gotten have been disappointingly soggy by the time they got to my door.
I'm a reasonably experienced person and I've found myself much _less_ productive at home, because despite my experience I still get value from being able to easily and quickly bounce ideas off people or get help in components that I'm less familiar with.
Sorry, the 4x was my estimate of Ignition vs. Sparkplug (I guess it's closer to Iain's estimate of 2-4x). Sparkplug vs. TurboFan is crazy workload dependent. For microbenchmark-y tight loops, integer attorneys, and clean single-shape ("monomorphic") property loads, TurboFan is orders of magnitude faster. For small functions that just have non-inlineable function calls and heavily polymorphic property loads (with lots of shapes so you can't skip the property lookup), like you see in a lot of web code, they're close to on-par (because there's nothing TF can optimise away). If you put a gun to my head, I'd say it's on "average" maybe 10x? Very much a Fermi approximation though.
"Ignition" was the codename for the entire interpreter project, including both the Ignition compiler and the Ignition interpreter. So the answer to your question is "yes".
It had massive technical debt. Both Ignition and FCG had to compile from source, and we had to be able to tier up from both of them up to TurboFan, so TurboFan maintained two front ends - one to compile from bytecode, and one to compile from AST. There was all sorts of complexity then around deoptimisation point IDs, maintaining consistent suspension points for generators/async functions, maintaining consistent type feedback across Ignition and FCG. Even better, for a while we had Crankshaft in there too as an optional "alternative" top-tier (while we were working on TurboFan), in a configuration we called the "Frankenpipeline". You can see that wonderful mess on slide 26 of this presentation: https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6H... (from this talk: https://youtu.be/r5OWCtuKiAk)
Three tiers is perfectly fine if the complexity is handled well, I could even see us adopting a fourth tier at some point in the future (not dissimilar indeed to JSC), most likely between Sparkplug and TurboFan.
Those vary widely too, depending on what (and more importantly, how many) object shapes they see. They'll be roughly the same cost in Ignition and Sparkplug though, since they effectively call the same handlers for those loads (and way faster in TurboFan, since that one then can generate optimised code tailored to that type feedback)
Author here: ah well, you win some, you lose some. This is just v1 that's shipping with M91, we've already made improvements since then and there's plenty more low hanging fruit to pick, heuristics to tweak, etc.
Author here: this is indeed just relative score change, the M1's absolute values are of course impressively high. My personal, unofficial suspicion is that this has something to do with the size of the M1's reorder buffer being so large that it can just predict and speculate straight through all the interpreter overheads; but that's just a guess.
Author here: we do have various numbers collected here, with varying levels of "I'm sure enough about these numbers to share them in a public blog post".
Compile time is on roughly the same order of magnitude as Ignition compilation (just AST to bytecode, so excluding parsing), and roughly two to three orders of magnitude faster that TurboFan. The relative performance to the interpreter, as the sibling comments point out, varies _wildly_ by workload, but around 4x is probably a decent approximation for something not entirely dominated by property loads.
Author here: we did, and as other comments say we removed it in favour of Ignition, with the intent of at some point in the future bringing back some form of baseline compiler.
The big difference is that Sparkplug compiles from bytecode, not from source, and thus the bytecode stays the source of truth for the program. Back in the FCG days, the optimising compiler had to re-parse the source code to AST, and compile from there - even worse, to be able to deoptimise back to FCG, it had to kind of "replay" FCG compilation to get the deopted stack frame right.
We did actually have a configuration (never released) that had Ignition, FCG, _and_ TurboFan, and boy was it a mess...
There's a certain sweet irony to this article saying that Erwin Kreuz was from a village near "Augsberg" in Bavaria; if one indeed were to try to go to "Augsberg, Bavaria", they would find themselves in a) a real but tiny place, and b) quite far away from Augsburg, Bavaria, where Kreuz was _actually_ from.
This post is unfortunately nonsense, because it's making a fundamental measurement error: not including renderer processes for Safari, and only measuring the browser process (which should be expected to be roughly O(1) memory in the number of tabs).
To the author's credit, they _are trying_ to include child processes - I'm not sure why, but `psrecord` seems to not (in local testing) include child processes for Safari even when the "--include-children" flag is passed. I guess it does for Chrome, for whatever reason.
I'm somewhat disappointed that the author, or half the comments on the post, didn't question these _wildly_ different results though...
I don't necessarily disagree, but there's a certain irony in presenting a claim of "how things are these days" in such a matter-of-fact way. I certainly wouldn't know how to refute your statement in a sufficiently short way. Thus, is it the presentation of claims that is the issue, or is it their content? Or both? I struggle with avoiding hypocrisy when trying to pinpoint the underlying problem.