Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

hacks.mozilla.org

Post reply on HN
Print view View original

91–100 of 281 posts

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

#91

Post by SomeOldThrow »

the_duke wrote: post #12

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…

Confluence is also pretty bad on firefox for whatever reason, so I'm pretty sure this is going to be a problem wherever chrome is the dominant browser in the dev culture there.

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

#92

Post by dymk »

xamuel wrote: post #89
_bxg1 wrote: 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…

One way to see it's more subtle than meets the eye: suppose the website defines a function F which is annotated as taking a string argument. The website itself only ever calls F with strings. But suppose I go to the website, open the console, and punch in F(1). Of course, this sort of thing could be guarded against, but the point is just that it would introduce more complexity than initially meets the eye.

Engines already have to do this - check the type of an argument before calling the compiled version of the function. What the OP is suggesting is simply prefilling the type and instruction caches with information that the build system was already able to gleen.

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

#93

Post by _bxg1 »

xamuel wrote: post #89
_bxg1 wrote: 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…

One way to see it's more subtle than meets the eye: suppose the website defines a function F which is annotated as taking a string argument. The website itself only ever calls F with strings. But suppose I go to the website, open the console, and punch in F(1). Of course, this sort of thing could be guarded against, but the point is just that it would introduce more complexity than initially meets the eye.

And that would probably amount to a "bailout". I'm only talking about providing hints that can be used to skip parts of the described process, not getting rid of it altogether.

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

#94

Post by dymk »

PaulHoule wrote: post #41
lkhhj wrote: post #19

Earlier quoted context omitted.

In what way is Chrome currently "a pain to use"?

It's at least "100% more evil" than other browsers. Google doesn't need to plaster the world with Google Analytics if it can get most people to use a browser that phones home. From around the time of the Windows 8 transition I used Microsoft Edge as much as possible. Firefox was at a low ebb then. I switched back to Firefox when Microsoft announced it would use the Chromium rendering engine for Edge. At that point Fi…

> It's at least "100% more evil" than other browsers.

oh god, it's like identity politics but "vim vs emacs!" flavored

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

#95

Post by saagarjha »

Quekid5 wrote: post #75
gok wrote: post #65

Earlier quoted context omitted.

> Do you have numbers to back that up? Hm hard to come up with a number that shows JS optimizations are hard, but you can peruse a collection of Javascript engine CVEs: https://github.com/tunz/js-vuln-db Notice how many are JIT or optimization issues, or are in esoteric features like async generators or the spread operator.

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 out-of-bounds. And I'm assuming many of these are heap corruptions where someone messes with a length that lets them get out-of-bounds.

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

#96

Post by WorldMaker »

_bxg1 wrote: post #83
WorldMaker wrote: post #80

Earlier quoted context omitted.

JS tried to add (optional) type hints in the ES4 standard that was never adopted (outside of tangential things like ActionScript 3). It would be great if Typescript hints could pass right along to the JITs as useful optimization factors, but it currently sounds like TC39 would prefer not to recreate the disasters of ES4 and are staying out of type hints for the forseeable future. (Well-typed code should prevent most…

Yeah it's probably not worth it to add types to JS the language, but what if you could ship standard metadata files similar to source-maps that only included type information, which browsers could leverage to speed up compilation?

In the long term, I hope that at least a compromise like the Python annotation approach could be reached (standardize the parsing, but ignore the semantics). Typescript type annotations share a surface level syntax with them in some ways, and also with ES4's type annotation attempt.

"Type maps" are an interesting idea. You could probably piggy back on/boostrap from WASM types.

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

#97

Post by michaelmrose »

pitaj wrote: post #69
mehrdadn wrote: post #66

Earlier quoted context omitted.

> Still waiting on Firefox to support hardware-accelerated decoding of videos though. Wait, Firefox doesn't do this already? Didn't know.

I'm fairly certain it does it already.

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.

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

#99

Post by patrickmcnamara »

mehrdadn wrote: post #66
patrickmcnamara wrote: post #53

Earlier quoted context omitted.

YouTube is faster on Firefox on my laptop for some reason. I get zero dropped frames on Firefox too, compared to Chrome/Chromium. Still waiting on Firefox to support hardware-accelerated decoding of videos though.

> Still waiting on Firefox to support hardware-accelerated decoding of videos though. Wait, Firefox doesn't do this already? Didn't know.

Forgot to mention that I use GNU/Linux. My bad.

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

#100

Post by usepgp »

chao- wrote: post #73
the_duke wrote: post #12

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…

Hey, I'm on the chromium videostack team, would you mind filing a bug report for what you see happening with youtube? https://bugs.chromium.org/p/chromium/issues/entry
Post reply on HN