I'm sorry, I do not understand from the article what the Baseline Interpreter is or does. It keeps the Baseline Compiler from having to compile so many functions by turning some sections into bytecode first?
The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
201–210 of 281 posts
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#202The idea of generating an interpreter from the compiler is really neat. What I missed in this article is why the Baseline Interpreter is faster than the C++ interpreter. The code snippet for the load zero instruction looks like what a compiler should produce for a straightforward C++ switch case for that instruction. Except that the code uses a push instruction to store the value directly on the system stack, whereas…
> Is that the difference, or am I missing something else?
That's part of it. The generated interpreter should be a bit faster for simple instructions because of the reason you give (also: things like debugger breakpoints have more overhead in the C++ Interpreter).
However, the bigger speedups are because the generated interpreter can use Inline Caches like the Baseline JIT. The C++ Interpreter does not have ICs.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#203I wouldn't be surprised if improvements in Javascript execution will make webassembly obsolete.
It already has a slim advantage of being 2x faster.
And Javascript has so many advantages in terms of handling. No compilation step needed at all. And since it has modules widely supported now, it is a joy to code in native Javascript without any libraries like React&Co.
Just look at how beautifully you can dynamically load code when it is needed in modern Javascript:
let calendar = await import('/modules/calendar.js');
calendar.askUserForDay("Checkin Date");Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#204Earlier quoted context omitted.
Are there any solid benchmarck comparing JSC vs v8?
JSC has had a set of large metabenchmarks like JetStream2 for a while. We have been the fastest for a while but V8 is gaining, so the current advantage is significant but not earth shattering. The last time V8 had their own benchmark, they retired it right after we beat them on it and made a post saying that benchmarks are bad because people cheat on them. Around that time I stopped seeing google.com claim that I sho…
I've always wished I could actually benefit from JSC without dropping a couple thousand dollars on a macbook and having to put up with the world's worst keyboard, because your browser team kicks ass :)
At least you're pressuring Mozilla and Google to step up their game on runtimes!
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#205I wouldn't be surprised if improvements in Javascript execution will make webassembly obsolete. It already has a slim advantage of being 2x faster. And Javascript has so many advantages in terms of handling. No compilation step needed at all. And since it has modules widely supported now, it is a joy to code in native Javascript without any libraries like React&Co. Just look at how beautifully you can dynamically loa…
You are possibly right, but it would be sad if we our choices for writing programs with a UI are: write in javascript or compile to javascript. There are many languages out there, webASM would allow them to work without the massive pain of cross-compilation.
I guess I am just an idealist screaming about how packet switched networks are unreliable and we should all use circuit switched networks.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#206Earlier quoted context omitted.
As far back as I remember the code behind sync was on GitHub and I do mean the backend. It probably still is. But I let Mozilla host it cause they encrypt it. If I lose my password I lose my synched items.
Nothing stressed me out more than the time I genuinely forgot my FF password for a few days!
If it's for a few days, how did you un-forget?
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#207I wouldn't be surprised if improvements in Javascript execution will make webassembly obsolete. It already has a slim advantage of being 2x faster. And Javascript has so many advantages in terms of handling. No compilation step needed at all. And since it has modules widely supported now, it is a joy to code in native Javascript without any libraries like React&Co. Just look at how beautifully you can dynamically loa…
You are possibly right, but it would be sad if we our choices for writing programs with a UI are: write in javascript or compile to javascript. There are many languages out there, webASM would allow them to work without the massive pain of cross-compilation. I guess I am just an idealist screaming about how packet switched networks are unreliable and we should all use circuit switched networks.
If you want to use a different language, why would you care about the compile target?
Compiling is done by the compiler. So to the developer it is the same. No matter if it comiles to Javascript or Webassembly.
In the end, I don't think writing code for the web in languages other then Javascript will take off. Simply because Javascript will always evolve to fit this specific environment. And therefore will always be the best choice. While other languages will evolve to be the best fit for their niche.
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#208The idea of generating an interpreter from the compiler is really neat. What I missed in this article is why the Baseline Interpreter is faster than the C++ interpreter. The code snippet for the load zero instruction looks like what a compiler should produce for a straightforward C++ switch case for that instruction. Except that the code uses a push instruction to store the value directly on the system stack, whereas…
The article called it a threaded interpreter, the answer to this question explains what that usually means and why it it faster: https://stackoverflow.com/questions/3848343/decode-and-dispa... I found the explanation of what they're doing a little unclear though and it seems they might not be doing exactly what is described in the answer above.
The dispatch part of the code snippet looks to me like what you would also get with computed gotos. Something like goto instruction_labels[++pc]. So that shouldn't be the difference, compilers can compile this well.
As for whether this is "threaded", and exactly what kind of threading it is, there is widespread confusion and abuse of terminology. https://en.wikipedia.org/wiki/Threaded_code
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#209The idea of generating an interpreter from the compiler is really neat. What I missed in this article is why the Baseline Interpreter is faster than the C++ interpreter. The code snippet for the load zero instruction looks like what a compiler should produce for a straightforward C++ switch case for that instruction. Except that the code uses a push instruction to store the value directly on the system stack, whereas…
> Is that the difference, or am I missing something else? That's part of it. The generated interpreter should be a bit faster for simple instructions because of the reason you give (also: things like debugger breakpoints have more overhead in the C++ Interpreter). However, the bigger speedups are because the generated interpreter can use Inline Caches like the Baseline JIT. The C++ Interpreter does not have ICs.
Ah, yes, inline caching probably explains it. Thanks!
Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70
#210Earlier quoted context omitted.
JSC has had a set of large metabenchmarks like JetStream2 for a while. We have been the fastest for a while but V8 is gaining, so the current advantage is significant but not earth shattering. The last time V8 had their own benchmark, they retired it right after we beat them on it and made a post saying that benchmarks are bad because people cheat on them. Around that time I stopped seeing google.com claim that I sho…
I've always wished I could actually benefit from JSC without dropping a couple thousand dollars on a macbook and having to put up with the world's worst keyboard, because your browser team kicks ass :) At least you're pressuring Mozilla and Google to step up their game on runtimes!
And even worse: run proprietary software, because that is what Apple do.