Live data from Hacker News

The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

hacks.mozilla.org

121–130 of 281 posts

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

#121

Earlier quoted context omitted.

It is mostly par with Chrome now pretty much everywhere. Well browsing most website should not trigger lag in any browsers. But if we look at benchmarcks: https://www.phoronix.com/scan.php?page=news_item&px=Firefox-...

Baseline interpreter is a good example of doing things that help most Web pages instead of benchmarks. One of the major things that ARES-6 and other benchmarks test is whether generators are JIT'd, for example. This doesn't really help Web pages, as it's a rarely used feature at present and even rarer in hot loops. SpiderMonkey should get around to jitting generators, but I have a hard time blaming the team for focus…

Pcwalton! While I agree that most synthetic benchmarcks are mostly not representative for the real world, there is a benchmarck suite for real world.

That is benchmarcking most used ALEXA websites. It's named TP 5 and TP6, mozilla use it internally (e. G to measure progress on stylo) Why is the real world (TP5/6) not public?? Phoronix has never used it, mozilla has never publicly published benchmarcks. I guess they favor chromium but I've never seen all results only the few mozillians posted on bugzilla. Let the world know, publish the results, even if it favor chromium. Anyway the mainstream will never be affected by that public information (most people have difficulties discerning a search engine from the concept of browser, let alone talking about benchmarcks)

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

#122
post #73

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 have the opposite experience with YouTube. With an AMD GPU on Linux, Chrome churns, drops frames, and stutters horribly on even 1080p videos at 30fps. Firefox, meanwhile, handles 1440p60 video with no problem. Even two such videos simultaneously, on separate monitors. Chrome became inexplicably better for parts of early 2019 (I did not note which versions), but starting 2 or 3 months ago Chrome returned to being un…

Check about:gpu - sounds like hardware acceleration isn't working.

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

#123

Earlier quoted context omitted.

There's already a JIT for JS coded in Rust: https://blog.mozilla.org/javascript/2017/10/20/holyjit-a-new... The overall goal is to have Firefox recoded in Rust, why would a JavaScript interpreter be left out? https://wiki.mozilla.org/Oxidation That's the whole point of Oxidation.

Of course they can do it. I just dont think is a clever move for them to do it. Firefox is having a hard time to compete with Chrome, and they took too long pursuing other goals, and just remembering one key feature they took a lot of time to implement, was making Firefox a the multi-process browser as Chrome. I mean, you would be ditching all this effort, rewriting it in Rust, spending key resources only to have som…

I see, I think we agree with each other, we are looking at things from a different angle is all. Thanks for the clarification, I do want Mozilla to succeed, we need other similar orgs to come out and be willing to compete with tech giants like Google as well, maybe Apache, but they're too busy being a giant corporate project dumping ground I suppose.

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

#124

I'm waiting to hear about when they start to rewrite their JS interpreter in Rust. It will make things kind of interesting, especially if it becomes a stand-alone capable JS inrepreter.

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…

> Javascript VM´s these days are fairly complex beasts with huge amount of man-hour and expertise.

You know what else is a MASSIVE time and money sink? C/C++.

Combining 2 big and nasty complex stuff you get something even bigger.

----

I don't say to blind rewrite. Is know to be:

> an exercize in vanity and why not say it, stupidity.

But this must take in account TIME. Right now, is not the time for a rewrite, but is better to have it planned.

----

I'm not naive saying this. This is my life (as a rewriter of codebases for several years and many projects). I'm moving a medium sized ERP project to Rust. In parts, too. Focusing in data exchange, yes. But if we don't do it, then the complexity behind will kill us.

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

#125

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…

It is mostly par with Chrome now pretty much everywhere. Well browsing most website should not trigger lag in any browsers. But if we look at benchmarcks: https://www.phoronix.com/scan.php?page=news_item&px=Firefox-...

Does anyone know if those same phoronix tests have been run against the new Firefox 70 Nightly or Developer Edition apps?

I'd be curious to see how 68 versus 69 versus 70 compare.

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

#126

Earlier quoted context omitted.

It uses the GPU but doesn't use it to actually decode video on linux. https://bugzilla.mozilla.org/show_bug.cgi?id=1210726 Bug opened 4 years ago. Hundreds of millions in revenue and can't task one person for a summer to hook into the support that already exists.

> Hundreds of millions in revenue and probably < 0.5% of it due to its linux userbase?

Linux distros tend to ship with firefox and linux users are more concerned with open source. It would be strange if the percentage of mozillas userbase using linux was smaller than the general percentage of pc users running linux.

Its probably more fair to go on profit not revenue.

100 million in revenue * 2.18% is 2.2 million. A decrease of 10% of that is 220k. If engineers at mozilla are 150k then 3 months of work is aprox 38k.

This would put the break even point at losing 2% of its linux users by not spending the money.

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

#127

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 wanted to keep using FF despite being a gmail user so much so that I switched to Thunderbird for my emails. I guess Mozilla wins this way.

I thought Thunderbird was not under development anymore?

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

#128
post #42

Earlier quoted context omitted.

I solve this by using Firefox for all web browsing, and Chrome for gmail/gapps/anything by google. It sucks that we have to do that, but I can't entirely blame them for making their own products work better on their own browser.

> It sucks that we have to do that, but I can't entirely blame them for making their own products work better on their own browser. You mean like MS for a long time did with MSIE? Are we really back in the 90s, back to “This page works best in $one_specific_browser”? This is not the future I was hoping for... On the flip side I can use Linux for almost anything, so i guess it’s not all bad.

> Are we really back in the 90s, back to “This page works best in $one_specific_browser”?

Do webdevs really check for Chrome AND Firefox compatibility? The devs I know consider the job done as long as their site works with Chrome.

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

#129
post #75

Earlier quoted context omitted.

That's fair and I now know more. I'm not convinced that this is the biggest issue with JS engines/browsers, but I certainly have more evidence against me :). It's interesting how many of those are labeled OOB. Does that mean that we're talking JIT flaws that allow OOB access to memory? Is it's actually tricking the JIT itself into allowing OOB access, or is it actually OOB'ing the JIT? I wonder what the performance i…

> Is it's actually tricking the JIT itself into allowing OOB access, or is it actually OOB'ing the JIT? What's the difference between the two? Many JavaScript exploits abuse the interaction between strange features of the language to get around bounds checks (often, because a length was checked but invalidated by later JavaScript executing in an unexpected way, or a bound not forseen as needing a check) leading to an…

[deleted]

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

#130
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 this for JS).

It's weird that they kept the C++ interpreter. But not too weird, if the IC logic in the new interpreter is costly. In the LLInt, the IC/type logic is either a win (ICs are always a win) or neutral (value profiling and case flag profiling costs nothing in LLInt).

Also worth noting that this architecture - a JIT ABI interpreter that collects types as a bottom tier - is older than any JS engine. I learned it from HotSpot, and I guess that design was based on a Strongtalk VM.

This is the current state of the art of JSC's bottom interpreter tier FWIW: https://webkit.org/blog/9329/a-new-bytecode-format-for-javas...

Post reply on HN