Live data from Hacker News

The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

hacks.mozilla.org

81–90 of 281 posts

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

#81
post #42

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

Rambox was a FOSS desktop app based on Electron to house all your Chrome apps in tabs.

Rambox went proprietary, but was forked into Hamsket. Might be easier than what you're using now.

https://github.com/TheGoddessInari/hamsket

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

#82

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.

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

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

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?

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

#85
post #79
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…

You can with asm.js: https://2ality.com/2013/02/asm-js.html

That's not the same thing; asm.js is a precursor to WASM which is a bytecode language that doesn't include garbage collection, and asm.js is actually an interpreter for it that's written in JS. The JS bytecode the article talks about is generated from JS and interpreted by C++.

In other words, it isn't practical to compile JS to WASM, and especially not to asm.js. The browser's JIT compilation of JS targets something completely different.

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

#86

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

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 focusing on real-world improvements first.

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

#87
post #13

Javascript engines gave up on interpreters too quickly. JITs have been a huge source of security holes, and the language is so huge now that verifying the correctness of JS optimizations is extremely hard. JS was never meant to be a high performance language. Plus all the heroic work on exotic optimization has just resulted in induced demand. Web pages have just grown to contain so much Javascript that they're even s…

I mostly disagree, but I appreciate your opinion - it adds a valuable viewpoint that needs to be considered. Opinions on this matter may arise from the dichotomy Martin Fowler describes between an "enabling attitude" and a "directing attitude" in software development: https://martinfowler.com/bliki/SoftwareDevelopmentAttitude.h... You're right that web apps have become extremely JS- and framework-heavy. Just like add…

The best performers can use WASM, I suppose.

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

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

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

#90
post #69

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 says its using the GPU but if you look at the cpu time required to play a 1080p video within firefox vs playing the same video with mpv

www.mpv.io : a lightweight player that among other things can transparently stream any url understood by youtube-dl

It uses 20x as much cpu as mpv. For purposes of comparison this is like Toyota selling a car that goes just as fast as your Ford so long as you are OK with only getting 4MPG.

There is an addon if you prefer to right click on a url and open in mpv or in an addon like Tridactyl you can do the same with your keyboard. It also lets you speed up and slow down the playback speed which is nice for speakers who talk too slow and take a while to get to the point.

Post reply on HN