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

221–230 of 281 posts

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

#221

Post by josteink »

copperx wrote: post #128
josteink wrote: post #103

Earlier quoted context omitted.

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

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

That would technically only make them Chrome-devs.

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

#222

Post by mehhh »

nwallin wrote: post #184
usepgp wrote: post #100

Earlier quoted context omitted.

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.

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.

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

#223

Post by XCSme »

_bxg1 wrote: post #85
XCSme wrote: 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…

I was mostly replying to this: "JS developers don't have the option to send along some of this information themselves; type information, JS bytecode", that in JS you can send some type information with asm.js hints (or TypedArrays), but yes you don't send it directly to the C++ interpreter, but to the JS interpreter, which presumably will pass it further.

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

#224

Post by thegeomaster »

FreeHugs wrote: post #203

I wouldn't be surprised if improvements in Javascript execution will make webassembly obsolete. It already has a slim advantage of being 2x faster. And Javascript has so many advantages in terms of handling. No compilation step needed at all. And since it has modules widely supported now, it is a joy to code in native Javascript without any libraries like React&Co. Just look at how beautifully you can dynamically loa…

WebAssembly will never become obsolete (in a technical sense, who knows what will happen in practice) as long as there are use-cases that require predictable and consistent performance. I predict these will become plentiful as more and more companies build web apps for increasingly performance-sensitive niches.

I'm not talking so much about raw speed, it's more about latency. Things such as realtime audio in the browser, non-CSS-driven animation, 3D (or any kind of realtime graphics, really), tight UIs where feedback must be very fast to be useful, etc. In lower-level languages, you must sometimes go as far as to avoid all memory allocations in one critical path. It's very hard to do so in JavaScript, especially when you take into account the prevalent coding style and functional nature of the language.

As long as you have GC and a dynamic type system which requires JIT heuristics to achieve that 2x speedup, you will always have cases of pathological latency which degrade the experience. When you measure raw speed in benchmarks, you amortize all of the jitter.

Now, whether the market is such that it will be satisfied by apps with this behavior is another story.

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

#225

Post by the_why_of_y »

jedberg wrote: post #44
faitswulff wrote: post #3

Earlier quoted context omitted.

I was perfectly fine with Chrome's usability until I started getting a `Hold Command + Q` to quit` prompt on my Mac. Before then, I hadn't even considered the possibility that an application could block me from quickly and easily quitting out of it. Now I have to hold the key combo or double tap it to quit Chrome, and it is the only application I have to do that for. It's so annoying.

Ironically, I love that feature and wish I could have it on my other apps, especially on Firefox. I've fat fingered Cmd-W and Cmd-Q too many times, and while it's easy to restore, it takes a couple minutes, a lot of bandwidth, and spins the CPU to 100% for a while. Which really sucks when you're on battery.

Firefox: about:config, set browser.showQuitWarning to true

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

#226

Post by pjmlp »

vetinari wrote: post #218
JohnBooty wrote: post #195

Earlier quoted context omitted.

What would you consider a huge userbase? Firefox has 230 million monthly users, using FF for an average of over 5 hours per day. https://data.firefox.com/dashboard/user-activity

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.

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

#227

Post by pjmlp »

pizlonator wrote: post #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…

And also the way Java and .NET are converging, by having both AOT/JIT on the box, alongside JIT caches.

There is also the whole ART reboot, where Google made the mistake of not doing AOT the same way as Microsoft did for the Windows Store, by compiling on the device instead of the more beefy store cluster, so they ended up with a mix of fast interpreter written in straight Assembly, a first tier JIT with PGO, and an AOT compiler that takes PGO profiles and really optimizes the critical paths while the device is idle. This circle goes around every time the application is updated or PGO information gets invalidated.

Likewise .NET Native had a few issues with reflection, so .NET Core 3.0 is bringing mixed AOT/JIT into the mix, with further improvements planned for .NET Core 5.

And on the Java world, after a couple of decades with separate AOT (comercial) and JIT toolchains, also the more widespread JDKs are going with both.

So everything new is old again, given the AOT/JIT experiments from Smalltalk, Eiffel, Oberon and Lisp. :)

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

#228

Post by pjmlp »

WorldMaker wrote: post #80
_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…

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…

Which is kind of ironic given WebIDL.

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

#229

Post by yusukesuzuki »

littlestymaar wrote: post #191
yusukesuzuki wrote: post #182

Earlier quoted context omitted.

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.

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 ;)

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

#230

Post by pjmlp »

mamcx wrote: post #124
oscargrouch wrote: post #106

Earlier quoted context omitted.

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…

Depends, using WinUI, Qt or Gtkmm is way faster than Gtk-rs, regarding productivity.
Post reply on HN