Live data from Hacker News

The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

hacks.mozilla.org

231–240 of 281 posts

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

#231

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?

Everything is turned into bytecode anyway. The Baseline Interpreter interprets the bytecode faster than the C++ interpreter, which allowed them to send less code to the JIT compiler.

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

#232
post #222

Earlier quoted context omitted.

Fixing this would be like eight steps forward: https://bugs.chromium.org/p/chromium/issues/detail?id=137247 The annoying part is that hardware acceleration works on chrome OS, so we know the support is buried in there somewhere.

Google closed that as Won't Fix, they are very opinionated and steadfast in their opinion as an organization. I doubt they will take Linux outside their own walled gardens seruously, Google has already shown their indifference to us Linux users.

They opened it as Won't Fix, which appears to be their way of saying that they'll accept work but it has a priority of less than zero.

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

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

Just like you can't blame Microsoft for making ActiveX work best on Windows.

If they did it while talking about open standards, then we would.

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

#234
post #226

Earlier quoted context omitted.

Given that Linux has 2% desktop market share (let's be generous) and Firefox has 10% (let's be generous the same way), that would mean that Linux has potential to be 20% of Firefox users. Is that something you are going to ignore? Many executives would sell their families for less opportunity.

The big difference is that those executives would be getting money out of those 20% customer base. I seriously doubt that those 20% Firefox users even consider doing a $1 donation.

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

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

#235
post #68

Something I'm curious about is why JS developers don't have the option to send along some of this information themselves; type information, JS bytecode, etc. Given that we often have it on hand already (TypeScript) or could integrate it into our build process (webpack). Obviously plain JS needs to still work without all that, but it could be a compelling point of optimization for large-scale apps. Perhaps the JS byte…

Deno[0], a project from the original author of Node, will natively run TypeScript, so I'm hoping it will have some of those sorts of optimizations. [0] https://github.com/denoland/deno

It doesn't natively run typescript, it just includes a webpacked version of the typescript transpiler.

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

#236
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…

It's not much of a difference in terms of consequences, but always-on bounds checking could alleviate OOB'ing the JIT at least.

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

#237

Earlier quoted context omitted.

As the gp said, async/await is rarely used in hot loops, so it would probably never get jit-ed in a real webpage.

I don’t agree given that async iterator can be iterated. But I’m ok if SpiderMonkey folks thinks so ;)

Async is mainly useful for asynchronous operations, like network requests if file system access. If used in this context, the loop cannot be "hot"…

Maybe there are people (ab)using the async stuf do do something else, but at least it's not really common.

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

#238

Earlier quoted context omitted.

Gmail is really crazy slow on Firefox, it’s such a deal breaker. I have regularly 30s to load the web application, it’s closer to 2-5s on Edge with the same setup (same ad blockers, etc).

I suspect this is because chrome supports WebSQL while Firefox does not.

I suspect you have suspected incorrectly: https://developers.google.com/web/tools/lighthouse/audits/we...

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

#239

Earlier quoted context omitted.

As the gp said, async/await is rarely used in hot loops, so it would probably never get jit-ed in a real webpage.

I don’t agree given that async iterator can be iterated. But I’m ok if SpiderMonkey folks thinks so ;)

I'm sure SM will get around to jitting that stuff at some point. All I'm saying is that Baseline Interpreter gives users bigger wins right now.

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

#240

Earlier quoted context omitted.

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

Did you look at the raptor dashboards? Let me help you: https://treeherder.mozilla.org/perf.html#/graphs?timerange=2...

Thank you! But without being able to compare it with chromium the results are meaningless to my brain.
Post reply on HN