Live data from Hacker News

The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

hacks.mozilla.org

181–190 of 281 posts

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

#181

Earlier quoted context omitted.

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.

I don't think it has yet been done. But as you probably noticed he tested with webrender too

I mean, WebRender and spidermonkey are two separate things.

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

#182

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…

JSC's async-await is constructed on the generator's mechanism so that high performance generator is critical for all the web code using async functions. Not sure how SpiderMonkey is doing.

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

#183
post #179

Earlier quoted context omitted.

They released a new version on the 27th of August[1]. It looks like it that was the first release since August 2018[2]. [1]: https://www.thunderbird.net/en-US/thunderbird/68.0/releaseno... [2]: https://www.thunderbird.net/en-US/thunderbird/60.0/releaseno...

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.

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

#184
post #100
post #73

Earlier quoted context omitted.

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

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.

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

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

Nah. I means Extended Support Release. After Firefox moved to the quicker release train, larger organizations were annoyed because they like stability in order to test stuff prior to release and make sure extensions and everything remains the same. So like Ubuntu (iirc) and some others, they created a Firefox ESR that gets security updates and only major updates ~once a year. I think Thunderbird actually just tracks with Firefox ESR.

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

#186
post #85
post #79

Earlier quoted context omitted.

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…

The point is, if you care about performance use asm.js. If you don’t then just use whatever standard path browsers provide and any optimization they do is gravy.

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

#187
post #178

Earlier quoted context omitted.

Same for me, I tried the latest Nightly a couple days ago to test the CoreAnimation work, and after 1 hour of use my Slack tab because so unbearably sluggish each keypress would take 1 second to render. No extensions, no GIFs, no heavy tabs open, perhaps one or two open tabs. No slowdowns at all after 8 hours on Slack w/ Safari or Brave. Firefox is definitely the worst browser on macOS, compared to the Windows versio…

I know about the CoreAnimation work. Hadn't heard about this accumulated sluggishness that you describe. Have you tried safe mode? A "Refresh"?

It was an installation from scratch, no leftover files or configs. And I actually did a manual refresh in the preferences.

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

#188
What's a good way to diagnose optimzation/deoptimization performance issues? The Z80 emulator I use for http://8bitworkshop.com/ has some long pauses while it's spinning up. It uses a huge generated switch statement, which I'd assume is hard to optimize if type info isn't complete. (I'm replacing it with a simpler emulator which works much better though)

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

#189
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

Unless he's making his own JS engine, it won't.

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

#190

I can't help but think that regardless what different browser vendors do there's no competition with v8. Like any language there is a standard library, or environment around it. V8 is to JavaScript what CPython is to python. At least in python you can use other versions and it's a very similiar environment. But if you want to use mozillas spidermonkey without Firefox, it's hoops and bounds worse experience. I'd argue…

About a decade ago I needed an embedded scripting language in a c++ project and chose JS. Embedding SpiderMonkey was a matter of copying all files in the `js` subfolder of the Firefox sources into my project, and calling into it was peanuts. The classes were well named, easy to use and easy to learn. Did this somehow change?

Nope.

JSC is even better in that regard - it’s API and ABI stable so you can just link to the[1] system install and use it [2].

[1] on Linux there are multiple (although technically it could be made to have a single lib for qt,gtk,wx...

[2] ok, actually using the C API is very very clunky :-/

Post reply on HN