Live data from Hacker News

The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

hacks.mozilla.org

251–260 of 281 posts

Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

#251

I 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…

WebAssembly will never become obsolete (in a technical sense, who knows what will happen in practice) as long as there are use-cases that require predictable and consistent performance. I predict these will become plentiful as more and more companies build web apps for increasingly performance-sensitive niches. I'm not talking so much about raw speed, it's more about latency. Things such as realtime audio in the brow…

And then you have cases like Android where there was a FloatMath class, implementated in native code due to the dog slowness from Dalvik with floating point math.

After ART came into play, and its JIT started getting serious optimizations, doing regular Java math was faster than going over the JNI wall and FloatMath is now deprecated.

Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

#252
post #205

Earlier quoted context omitted.

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…

Because usually it ends up with debugging generated JavaScript at some point.

Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

#253
post #246

Earlier quoted context omitted.

Yea YouTube performance is nuts! It seems to be exacerbated when playing in full screen or @2x speed as well. Google has been getting better though with supporting FF. They now support Hangouts on FF and Gmail is actually faster for me in FF than it is in Chrome.

On Edge the slowness increases to the point that loading a ZX Spectrum game from tape feels psychologly faster. A mute point however now with EdgeChrome.

Not to nitpick, but it's "a moot point".

Fun fact, the word "moot" has the same origin as "meet". A "moot point" was originally "something that has to be discussed and decided at a meeting" (like a town hall or similar). Thus there was no sense in discussing it, since it was up to the meeting to decide. Also, scouts still call their congregations "a moot".

Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

#254
post #246

Earlier quoted context omitted.

On Edge the slowness increases to the point that loading a ZX Spectrum game from tape feels psychologly faster. A mute point however now with EdgeChrome.

Not to nitpick, but it's "a moot point". Fun fact, the word "moot" has the same origin as "meet". A "moot point" was originally "something that has to be discussed and decided at a meeting" (like a town hall or similar). Thus there was no sense in discussing it, since it was up to the meeting to decide. Also, scouts still call their congregations "a moot".

Thanks for the correction.

Nowadays I have two sources of errors when writing.

My own lack of knowledge, or incorrect knowledge, and then the stupid auto corrections that just go down the drain due to me mostly typing across multiple languages.

So whatever caused it, thanks again.

Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

#255

Earlier quoted context omitted.

To be fair i think this is an exercize in vanity and why not say it, stupidity. Javascript VM´s these days are fairly complex beasts with huge amount of man-hour and expertise. Also technically this would be a inferior solution as compared to what V8 did with its interpreter in Turbofan (and SpiderMonkey are doing now as presented in the article), by generating pure assembly through the turbofan backend (the same tec…

Couldn’t you say much the same thing about Firefox as a whole?

I think so, but with the Javascript VM i think this is more clear, to the spot.

As far as i know, the web rendering engine of Firefox in C++ were pretty old, coded in old c++ style. So in this particular case a rewrite would have some leverage.

The thing is, in the end, i dont know if this part C++, part Rust codebase wont start to create more problems than it solves.

Should the layout and rendering engine be rewritten in C++ or Rust? They decided to go with Rust, and now they will be forced to continue replacing C++ codebases with Rust, for consistency, workforce, etc..

In the end they will fight a lot to recode the browser, and meanwhile the competion can optimize, inovate and create more features.

Rust will gain a lot for sure, but not Firefox, not Mozilla. And with this Mozilla will be in a place where it will need to bet everything in Rust, as its only chance of survival.

End users dont care what technology go on their browsers, they care about perception, and its not clear that a browser will work better just because its in Rust as compared to C++ which is already a high performance language. (Maybe they will spend less resources in tests or in correcting bugs, but thats pretty much it)

Firefox is much better now than it was before? Yes, but my point is it could have been this better version of itself sooner, if they did not use Firefox to fight Rust´s cruzade to relevancy.

Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

#256

Worth noting that this basically means that all of the JS engines are converging on what JavaScriptCore pioneered: - More than just two tiers (JSC has four, and I guess Moz has four too now; I guess it's just a matter of time before V8 follows). - Bottom tiers must include a fast interpreter that uses JIT ABI and collects types (Ignition and this Moz interpreter smells a lot like JSC's LLInt, which pioneered exactly…

Hi @pizlonator, the link you posted mentions that direct threading isn't needed anymore.

I would have expected the Meltdown/Spectre mitigations to penalize indirect branches, making direct threading relevant again. From that post, I suppose it isn't the case, but I'd love to know more about it.

Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

#257
post #256

Worth noting that this basically means that all of the JS engines are converging on what JavaScriptCore pioneered: - More than just two tiers (JSC has four, and I guess Moz has four too now; I guess it's just a matter of time before V8 follows). - Bottom tiers must include a fast interpreter that uses JIT ABI and collects types (Ignition and this Moz interpreter smells a lot like JSC's LLInt, which pioneered exactly…

Hi @pizlonator, the link you posted mentions that direct threading isn't needed anymore. I would have expected the Meltdown/Spectre mitigations to penalize indirect branches, making direct threading relevant again. From that post, I suppose it isn't the case, but I'd love to know more about it.

JavaScriptCore uses indirect branches just as it did before Spectre.

Also, direct threading still means doing the same number of indirect branches as before, unless you implemented it as a tree of conditional branches. So direct threading doesn't change the Spectre situation one way or another.

Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

#258

The Mozilla tech blogs are always a good read. Informative and easy to digest. I can only think of one other company blogging with similar consistency/quality: Cloudflare. Firefox performance has seen tremendous gains since their Project Quantum efforts. It mostly feels on par with Chrome for me pretty much everywhere. There is one glaring omission though: a single company where I have problems with FF on multiple ap…

I don't know about Gmail or Docs, but IME (also on linux) Youtube doesn't work in any browser[0]; I'd recommend http://youtube-dl.org/ and a real video player.

0: Even with remote code execution vulnerabilities enabled it shows a corporate spam clip instead of the video I'm trying to watch.

Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

#259
post #179

Earlier quoted context omitted.

I believe Thunderbird is now ESR. So it gets a major version then security updates for a year until the next one.

What is the meaning of ESR? Because that sounds like life support to the layman.

Do you want your mail reader constantly tracking the latest web tech?

The layman hates updates.

Re: The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

#260
post #245

Earlier quoted context omitted.

Firefox makes money from the install base via the search engine default setting. Fairly sure more so than donations

Might be, is there any official numbers? After all plenty also switch to other search engines.

Are you sure? I bet 99% just leave it configured to use google.
Post reply on HN