7 ms·

> With our current two-compiler model, we can’t tier up to optimised code much faster; we can (and are) working on making the optimisation faster, but at some p

> With our current two-compiler model, we can’t tier up to optimised code much faster; we can (and are) working on making the optimisation faster, but at some point you can only get faster by removing optimisation passes [...] > Enter Sparkplug: our new non-optimising JavaScript compiler we’re releasing with V8 v9.1, which nestles between the Ignition interpreter and the TurboFan optimising compiler. This surprised me. Didn't V8 have a 'fast JIT' alongside an optimizing JIT as early as 2013? It was called full-codegen. Did they remove it? https://wingolog.org/archives/2013/04/18/inside-full-codegen-v8s-baseline-compiler https://wingolog.org/archives/2013/04/18/inside-full-codegen...

chrisseaton 5y ago
> This surprised me. Didn't V8 have a 'fast JIT' alongside an optimizing JIT as early as 2013? It was called full-codegen. Did you see the image at the bottom of the design document? That explains it.
- ptx 5y ago
  Where?
  - chrisseaton 5y ago
    https://docs.google.com/document/d/13c-xXmFOMcpUQNqo66XWQt3u46TsBjXrHrh4c045l-A https://docs.google.com/document/d/13c-xXmFOMcpUQNqo66XWQt3u...
    - MaxBarraclough 5y ago
      Thanks. For those following, see specifically FAQ > Isn’t this just FullCodeGen?
  - IainIreland 5y ago
    In the document here[1], there's a picture of Gandalf the White at the bottom with the caption "Sparkplug: I am FullCodeGen. Or rather, FullCodeGen, as it should have been". [1]:https://docs.google.com/document/d/13c-xXmFOMcpUQNqo66XWQt3u46TsBjXrHrh4c045l-A https://docs.google.com/document/d/13c-xXmFOMcpUQNqo66XWQt3u...
- justicezyx 5y ago
  I guess it's not obvious that answers with information are mostly adjective or preposition words are poor answer to engineering questions, because engineers are looking for (relatively) precise answers. For example: * What is bottom? Did it means one of the pictures in the bottom page. Or the absolute bottom. * What if the picture was not at the bottom, instead, it was followed by large chunk of texts? * What deisng doc? Was it mentioned in the parent post, or was it a "well known" design doc? * Design doc for which topic? Turbofan/Craneshaft/etc? (This is nitpicking, but still happen often because one might found this as the first sight, not following the thread. Again, reading answers for engineers are also a skill, quite different from reading, for example, science fiction, another day another topic) * What does the figure explain? What if the figure shows something that not match my concept of the question? In the end, answering engineering question, should be, and have to be, stating accurate facts. If and how that actually answers the question, is more depending on the readers and questioner's continued communication. Edit: To make sure I was not leaving wrong impression, those questions I listed above was encountered everyday for the answers I received. It's not nitpicking. You can read this thread for an example how answers without concrete information being inappropriate engineering answers.
  - coldtea 5y ago
    Note how we didn't learn anything (precise or not) about the answer to the question from this comment, but we did learn your preferences about communication styles.
    - justicezyx 5y ago
      Now the parent was gone, it seems I am random ranting... BTW, I view this as not about communication style, but communication efficiency.
- wonnage 5y ago
  I'm not sure how you'd expect people to find that since it's not linked from the article.
masklinn 5y ago
> Did they remove it? They removed it a while back after they introduced the ignition interpreter: v8 used to only have compilers (full-codegen and crankshaft, the latter being the jit optimising compiler, full-codegen was not a jit). One particularity of the pipeline was that since there was no interpreter both compilers worked from the source, which crankshaft had to keep around and re-parse. In 2013 they started working on a new optimising jit (turbofan), but for a while it didn’t really improve things (though the failure modes were often better than crankshaft’s). Then some engineers realised they could use part of turbofan for an interpreter, which would allow load sharing (amongst other things turbofan would jit ignition’s bytecode instead of having to re-parse from source), that brought in the improvements they were looking for, but then full-codegen was kinda sitting in the middle awkwardly with no integration, its low-end eaten by ignition and with no real high end. So it was dropped alongside crankshaft in v8 5.9. Now they’re reintroducing a non-optimising compiler, but one that’s integrated with the ignition-turbofan pipeline, and actually a jit.
- tom_mellior 5y ago
  > full-codegen was not a jit By what definition?
  - antpls 5y ago
    The way I understand the comment : With an interpreter, the JavaScript source is compiled to some bytecode, then the bytecode is executed in a loop, instruction by instruction. With a compiler (not jit), the whole bytecode would be further fully compiled to some C apis before being executed, making it effectively an "ahead of time" compilation. The catch is : since the code never was executed, there is very little static information to work with, so the compiled output is often just a giant unrolled interpret loop. The compiled version can be like 10% faster on very hot JavaScript loops compared to the interpreted version.
    - tom_mellior 5y ago
      > With a compiler (not jit), the whole bytecode would be further fully compiled to some C apis before being executed, making it effectively an "ahead of time" compilation. This hinges at least on the question of what you mean by "the whole bytecode". If the source is made up of N functions, and you compile all N functions ("the whole bytecode" of the entire program) to machine code before you know if any of them will be executed: Yes, I'd agree that that's a form of ahead of time compilation. Is this what full-codegen used to do? On the other hand, if the source is made up of N functions, and you only compile "the whole bytecode" of each of them to machine code one by one, only those that will actually be executed, and only when you are preparing to actually execute them: That's JIT compilation. Even if it is the very first execution (i.e., you have never even interpreted), even if the compilation doesn't use fancy profiling or sophisticated code generation or whatnot. > since the code never was executed, there is very little static information to work with, so the compiled output is often just a giant unrolled interpret loop I think you mean "dynamic" information. And "the compiled output is often just a giant unrolled interpret loop" is pretty much the definition of what a baseline JIT compiler produces.
Leszek 5y ago
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...
- MaxBarraclough 5y ago
  > We did actually have a configuration (never released) that had Ignition, FCG, _and_ TurboFan, and boy was it a mess... Do you mean it had technical debt that was never resolved, or do you mean 3 tiers is always too many? I believe WebKit's JavaScript engine currently has 4 tiers, [0] although that includes an interpreter as the first tier. [0] https://arstechnica.com/information-technology/2014/05/apple-integrates-llvm-compiler-to-boost-webkit-javascript-performance/ https://arstechnica.com/information-technology/2014/05/apple...
  - Gaelan 5y ago
    More recent source: https://webkit.org/blog/10308/speculation-in-javascriptcore/ https://webkit.org/blog/10308/speculation-in-javascriptcore/ The exact tiers have changed, but it’s still 4 of them: an interpreter (LLInt), the Baseline JIT, and two optimizing JITs
  - Leszek 5y ago
    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/1OqjVqRhtwlKeKfvMdX6HaCIu9wpZsrzqpIVIwQSuiXQ/edit?usp=drivesdk https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6H... (from this talk: https://youtu.be/r5OWCtuKiAk 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.

chrisseaton 5y ago

> This surprised me. Didn't V8 have a 'fast JIT' alongside an optimizing JIT as early as 2013? It was called full-codegen. Did you see the image at the bottom of the design document? That explains it.

ptx 5y ago
Where?
- chrisseaton 5y ago
  https://docs.google.com/document/d/13c-xXmFOMcpUQNqo66XWQt3u46TsBjXrHrh4c045l-A https://docs.google.com/document/d/13c-xXmFOMcpUQNqo66XWQt3u...
  - MaxBarraclough 5y ago
    Thanks. For those following, see specifically FAQ > Isn’t this just FullCodeGen?
- IainIreland 5y ago
  In the document here[1], there's a picture of Gandalf the White at the bottom with the caption "Sparkplug: I am FullCodeGen. Or rather, FullCodeGen, as it should have been". [1]:https://docs.google.com/document/d/13c-xXmFOMcpUQNqo66XWQt3u46TsBjXrHrh4c045l-A https://docs.google.com/document/d/13c-xXmFOMcpUQNqo66XWQt3u...
justicezyx 5y ago
I guess it's not obvious that answers with information are mostly adjective or preposition words are poor answer to engineering questions, because engineers are looking for (relatively) precise answers. For example: * What is bottom? Did it means one of the pictures in the bottom page. Or the absolute bottom. * What if the picture was not at the bottom, instead, it was followed by large chunk of texts? * What deisng doc? Was it mentioned in the parent post, or was it a "well known" design doc? * Design doc for which topic? Turbofan/Craneshaft/etc? (This is nitpicking, but still happen often because one might found this as the first sight, not following the thread. Again, reading answers for engineers are also a skill, quite different from reading, for example, science fiction, another day another topic) * What does the figure explain? What if the figure shows something that not match my concept of the question? In the end, answering engineering question, should be, and have to be, stating accurate facts. If and how that actually answers the question, is more depending on the readers and questioner's continued communication. Edit: To make sure I was not leaving wrong impression, those questions I listed above was encountered everyday for the answers I received. It's not nitpicking. You can read this thread for an example how answers without concrete information being inappropriate engineering answers.
- coldtea 5y ago
  Note how we didn't learn anything (precise or not) about the answer to the question from this comment, but we did learn your preferences about communication styles.
  - justicezyx 5y ago
    Now the parent was gone, it seems I am random ranting... BTW, I view this as not about communication style, but communication efficiency.
wonnage 5y ago
I'm not sure how you'd expect people to find that since it's not linked from the article.

masklinn 5y ago

> Did they remove it? They removed it a while back after they introduced the ignition interpreter: v8 used to only have compilers (full-codegen and crankshaft, the latter being the jit optimising compiler, full-codegen was not a jit). One particularity of the pipeline was that since there was no interpreter both compilers worked from the source, which crankshaft had to keep around and re-parse. In 2013 they started working on a new optimising jit (turbofan), but for a while it didn’t really improve things (though the failure modes were often better than crankshaft’s). Then some engineers realised they could use part of turbofan for an interpreter, which would allow load sharing (amongst other things turbofan would jit ignition’s bytecode instead of having to re-parse from source), that brought in the improvements they were looking for, but then full-codegen was kinda sitting in the middle awkwardly with no integration, its low-end eaten by ignition and with no real high end. So it was dropped alongside crankshaft in v8 5.9. Now they’re reintroducing a non-optimising compiler, but one that’s integrated with the ignition-turbofan pipeline, and actually a jit.

tom_mellior 5y ago
> full-codegen was not a jit By what definition?
- antpls 5y ago
  The way I understand the comment : With an interpreter, the JavaScript source is compiled to some bytecode, then the bytecode is executed in a loop, instruction by instruction. With a compiler (not jit), the whole bytecode would be further fully compiled to some C apis before being executed, making it effectively an "ahead of time" compilation. The catch is : since the code never was executed, there is very little static information to work with, so the compiled output is often just a giant unrolled interpret loop. The compiled version can be like 10% faster on very hot JavaScript loops compared to the interpreted version.
  - tom_mellior 5y ago
    > With a compiler (not jit), the whole bytecode would be further fully compiled to some C apis before being executed, making it effectively an "ahead of time" compilation. This hinges at least on the question of what you mean by "the whole bytecode". If the source is made up of N functions, and you compile all N functions ("the whole bytecode" of the entire program) to machine code before you know if any of them will be executed: Yes, I'd agree that that's a form of ahead of time compilation. Is this what full-codegen used to do? On the other hand, if the source is made up of N functions, and you only compile "the whole bytecode" of each of them to machine code one by one, only those that will actually be executed, and only when you are preparing to actually execute them: That's JIT compilation. Even if it is the very first execution (i.e., you have never even interpreted), even if the compilation doesn't use fancy profiling or sophisticated code generation or whatnot. > since the code never was executed, there is very little static information to work with, so the compiled output is often just a giant unrolled interpret loop I think you mean "dynamic" information. And "the compiled output is often just a giant unrolled interpret loop" is pretty much the definition of what a baseline JIT compiler produces.

Leszek 5y ago

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...

MaxBarraclough 5y ago
> We did actually have a configuration (never released) that had Ignition, FCG, _and_ TurboFan, and boy was it a mess... Do you mean it had technical debt that was never resolved, or do you mean 3 tiers is always too many? I believe WebKit's JavaScript engine currently has 4 tiers, [0] although that includes an interpreter as the first tier. [0] https://arstechnica.com/information-technology/2014/05/apple-integrates-llvm-compiler-to-boost-webkit-javascript-performance/ https://arstechnica.com/information-technology/2014/05/apple...
- Gaelan 5y ago
  More recent source: https://webkit.org/blog/10308/speculation-in-javascriptcore/ https://webkit.org/blog/10308/speculation-in-javascriptcore/ The exact tiers have changed, but it’s still 4 of them: an interpreter (LLInt), the Baseline JIT, and two optimizing JITs
- Leszek 5y ago
  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/1OqjVqRhtwlKeKfvMdX6HaCIu9wpZsrzqpIVIwQSuiXQ/edit?usp=drivesdk https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6H... (from this talk: https://youtu.be/r5OWCtuKiAk 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.