22 ms·

The Baseline Interpreter: A Faster JavaScript Interpreter in Firefox 70

• fucking_tragedy 7y ago
  Awesome. I love the direction Firefox is heading now that Chrome is a pain to use.
  • faitswulff 7y ago
    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.
    • didip 7y ago
      This bugs me big time, I wonder what was the decision behind such inconvenient UX.
      • tracker1 7y ago
        I'm guessing Google apps like Hangouts and notifications. To keep you from accidentally completely closing. On Windows it silently keeps running in the background most of the time if you have apps or notifications running.
      • floatboth 7y ago
        How is it inconvenient? It prevent accidental quits! I use ctrl-q as my shortcut key in tmux. I can't count how many times I accidentally sent that into the wrong window :) I consider showQuitWarning in Firefox a necessity. IMO, no application ever should quit from one key combination without confirmation.
    • mikepurvis 7y ago
      I'm surprised that functionality isn't possible to disable, but tbh I really like it. Too many times a finger slip turns Cmd+W into Cmd+Q and suddenly I'm lost a whole pile of tab state, possibly even half-submitted forms. Yuck.
      • OskarS 7y ago
        Surely that can be restored? In firefox, if you accidentally close a window, there’s a “Recently closed windows” thing in the history menu you can use that brings back all the tabs.
        • deleted 7y ago
          [deleted]
        • rileyteige 7y ago
          That is true, however this results in all your tabs getting refreshed. For e.g. ProtonMail, this means you have to login (get out your 2FA device etc) all over again.
        • mikepurvis 7y ago
          It can, and things are better than ever as far as preserving (most) form state, sessions, and scroll positions, but it's not perfect. Just as one example, pages opened on one network (eg at work) won't be able to reload elsewhere unless I take the extra step of connecting to the VPN. This is not the end of the world, but it's an annoying detour when I really just wanted to close that one tab. And it's so rare that I shut down the whole browser anyway, so it makes sense to me to make it hard to do accidentally.
      • matheussampaio 7y ago
        It's possible to disable as mentioned in another comment.
      • roryokane 7y ago
        I worked around the accidental-Command-Q problem in Firefox by setting up a custom keyboard shortcut using the paid app Keyboard Maestro (https://www.keyboardmaestro.com/ https://www.keyboardmaestro.com/). I have a macro “Confirm Command-Q to Quit” that intercepts the ⌘Q keystroke, only in Firefox, and instead shows a floating dialog titled “Really quit Firefox?”. The Cancel button in the dialog stops the macro, and the Quit button continues the macro to the next step, which is a Quit Firefox instruction. Another possible workaround is to go to System Preferences > Keyboard > Shortcuts > App Shortcuts and create a new shortcut. You can specify that in the app Firefox, the menu item “Quit Firefox” should have the shortcut ⌥⌘Q. Then a normal ⌘Q should do nothing.
    • dagenix 7y ago
      To Disable: Uncheck "Warn Before Quitting" on the "Chrome" menu - in between the Apple menu and "File" menu.
      • mgkimsal 7y ago
        it doesn't help when you're testing via automated software - test runners will open up chromes, then often fail and leave them open, and the 'warn before quitting' is always defaulted to on.
        • duncanawoods 7y ago
          Pretty sure you can choose a profile with specific settings if launching from selenium or cli.
    • wodenokoto 7y ago
      This is extra weird because browsers have become really good at preserving state between closing and restarting. The real answer to potentially destructive moves is not to ask the user twice, but to let the user easily undo.
      • tracker1 7y ago
        It's also to keep chrome apps and notifications working. I use Hangouts a lot. Though I generally deny notifications for anything else. For most anything that I would use persistent I tend to use an external app anyway (even if it's just an electron wrapper).
    • elcomet 7y ago
      I actually love this and was waiting for this feature for a long time. I can't count the times I quit chrome by mistake. You can disable it though.
    • saurik 7y ago
      FWIW, this behavior is trivial to disable (though I agree it should not be on by default: I actually had remembered it not being on by default). It was really important for me, as once a month I would accidentally hit cmd-Q and then sigh the sigh of the damned as I wait for what is effectively a reboot of my entire computer (as the only two things I tend to have open are a terminal and a browser).
    • jedberg 7y ago
      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.
      • kderbe 7y ago
        I use the add-on "Disable Ctrl-Q and Cmd-Q" because of this. To actually quit with the add-on enabled, you must click the Quit Firefox menu item.
      • sa1 7y ago
        Easy to do with Hammerspoon: https://apple.stackexchange.com/a/349766 https://apple.stackexchange.com/a/349766
      • the_why_of_y 7y ago
        Firefox: about:config, set browser.showQuitWarning to true
    • olliej 7y ago
      Honestly as much as I dislike chrome the “hold cmd q” behavior has saved me many times and I kind of wish safari did it: cmd-q and cmd-w are very close to each other :)
  • nevir 7y ago
    V8 did this a while ago.
    • jandem 7y ago
      As far as I know V8 has a generated interpreter and an optimizing JIT (Turbofan). In Firefox we now have a generated interpreter + a Baseline JIT on top of a mostly shared code base. I think that's a pretty nice design/advantage.
      • deleted 7y ago
        [deleted]
      • nevir 7y ago
        Fair point!
  • lkhhj 7y ago
    In what way is Chrome currently "a pain to use"?
    • PaulHoule 7y ago
      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 Firefox had improved performance a lot and I've mostly been happy with it. The minus of it however is that many developers are choosing to only support Chrome. For instance I worked at a company that had developed a data analysis tool with a React front end and it didn't work with either Firefox or Edge (or Safari) so I had to install Chrome for work. I don't think there was a deep technical reason why that was, but rather they did not want to go through the effort to test on other browsers. Our customers weren't clamoring for wider browser compatibility so that was OK for the business. From time to time I find public web pages that have problems w/ Firefox, although more frequently I find pages that don't like it that I block ads at the "hosts" level. Some sites now use trackers as part of the authentication/anti-fraud process and that can be a problem. Believe it or not I hardly ever log into Google. I have a gmail account that I barely use, but when i do I IMAP into it with em client. I am really done with Adsense, Adwords, Analytics, and all that. If I am working for somebody that is using Google services I will use it, but otherwise I can go a month or two w/o logging into Google.
      • dymk 7y ago
        > It's at least "100% more evil" than other browsers. oh god, it's like identity politics but "vim vs emacs!" flavored
    • fucking_tragedy 7y ago
      Chrome regularly tries to trick me into logging into my Google account via Chrome. If you try to disable this functionality, updates will include new dark patterns to trick you into logging in anyway. Now if I log into any Google service, Chrome will magically log into my Google account, too. When I open Chrome, I'm greeted with a new tab with a login screen for my Google account. I don't want to have mess with a bunch of settings just to turn off anti-user features and tracking. I am willing to mess with a bunch of settings if it enhances the functionality of the application I'm using. Open 'about:config' in Firefox and look at all of the ways Firefox's behavior can be configured. I run my own Firefox Sync instance, because Firefox is just that customizable. Google regularly removes customization options from Chrome. I used to be able to Cast non-HTTPS resources from Chrome, then I had to enable a setting buried in its experimental features to do so. Now the feature is "enabled" in the settings, but after Chrome auto-updated a few times, the feature doesn't work at all. I can no longer install Chrome extensions from GitHub, even though I could a few weeks ago. Google decides to take extensions off of their Chrome Web Store, and then make it difficult to use extensions they don't approve of. Firefox uses less memory and CPU than Chrome does, I'm on a MacBook, so anything that unnecessarily drains my battery is a pain to use.
• mikepavone 7y ago
  One thing that wasn't clear to me from this post is why they still need the C++ interpreter at all. I assume there is some non-obvious cost that makes it not worth it for the coldest of code, but I'm having a hard time guessing what it may be.
  • evilpie 7y ago
    As mentioned in the blog-post, the Basline Interpreter uses the JitScript structure containing type and IC information. Allocating this additional struct is a waste of memory for a function that is only executed a handful of times, without ever actually using that information for optimizing.
  • deleted 7y ago
    [deleted]
  • jandem 7y ago
    > One thing that wasn't clear to me from this post is why they still need the C++ interpreter at all. A lot of code on the web is very cold (executed once or twice) and for such code the Baseline Interpreter would add some overhead (requires allocating a JitScript storing the IC data for example and we would then spend more time in IC code as well). It's possible this could be mitigated or fixed with additional work, but we need to keep the C++ interpreter anyway (not all platforms have a JIT backend and it's useful for differential testing) so it's not a priority right now.
    • deleted 7y ago
      [deleted]
    • mikepavone 7y ago
      Makes perfect sense, thanks for explaining it for me.
    • fbender 7y ago
      Can you run the baseline interpreter with the costly parts disabled? Even if the code then runs approx. the same speed (and at same cost) of the C++ interpreter, you‘d save maintaining a bunch of code. I assume implementing the missing backends offsets maintenance costs in the long term.
• the_duke 7y ago
  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 apps - Google. Gmail was still dog-slow the last time I tried, Youtube can send my fan into a frenzy and Docs is also regularly problematic. (on Linux)
  • The_rationalist 7y ago
    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-68-Chrome-76-Browsers https://www.phoronix.com/scan.php?page=news_item&px=Firefox-...
    • the_duke 7y ago
      Amended to "feels on par".
    • pcwalton 7y ago
      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.
      • The_rationalist 7y ago
        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 favor chromium but I've never seen all results only the few mozillians posted on bugzilla. Let the world know, publish the results, even if it favor chromium. Anyway the mainstream will never be affected by that public information (most people have difficulties discerning a search engine from the concept of browser, let alone talking about benchmarcks)
• gok 7y ago
  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 slower than they were when JS was slow. Browser vendors should agree to make JS slow and safe again like it used to be, forcing web developers to make their pages smaller and better for users. For the unusual cases like browser-based games, WebAssembly is ok (it's much easier to verify the correctness of a WASM compiler), and it should be behind a dialog box that says something like "This web page would like to use extra battery power to play a game, is that ok?"
  • Quekid5 7y ago
    > 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. Do you have numbers to back that up? There certainly have been 1 or more security holes in JITs, but AFAICT most of the browser vulnerabilities have more to with bad (new) APIs. The level where a JIT operates really has nothing to do with the surface syntax of JS, so adding "syntactic sugar" features to JS should have very little impact on JITs. (I'm thinking of things like the class syntax, lexical scope for function literals, etc. Maybe there's a class of additions that I'm missing.)
    • PaulHoule 7y ago
      I am more familiar with Java where the runtime implementations have gone back and forth through various iterations, such as Jazelle and various ways to accelerate Java on ARM, the various Android implementations, etc. What people think is the best choice of tiers to use is always evolving. One factor against JIT's is that modern chips and OS want to set the NX (no execute) bit against the stack and the heap which at least forces attackers into return-oriented programming. To JIT you have to at least partially disable that behavior.
    • gok 7y ago
      > 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 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.
• The_rationalist 7y ago
  Would be nice to see benchmarck comparing v8 vs new spidermonkey!
  • nerdponx 7y ago
    Equally interesting would be a side-by-side architecture comparison.
• devwastaken 7y ago
  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 that v8 is far less of a lock in by comparison. Given all that, why are we still creating entirely separate engines that are made differently, yet do the same.
  • damnyou 7y ago
    Because monocultures are bad.
    • The_rationalist 7y ago
      Is linux bad? Is git bad? Your argument needs a little more development.
      • damnyou 7y ago
        Linux is only a monoculture on the server. Server-side applications will sometimes use Linux -specific features but generally are written to be ported to other POSIX systems with little work. Of course the git monoculture is bad. Have you seen how many people complain about git on Twitter?
      • PeCaN 7y ago
        linux isn't a monoculture at all assuming you know about Windows and OS X and are just talking about servers, there's still the BSDs and Solaris and AIX. a good deal of software is written to just assume a reasonably POSIX-compliant environment, precisely because linux is not the only server OS. unix-like operating systems are something of a monoculture and that IS very bad, because OS design is basically stuck in 1973 >Is git bad? yes and anyone who says otherwise is numb to the pain
  • the_duke 7y ago
• joaobeno 7y ago
  I love those elemental animal names of their projects...
• _bxg1 7y ago
  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 bytecode just isn't standardized across browsers?
  • XCSme 7y ago
    You can with asm.js: https://2ality.com/2013/02/asm-js.html https://2ality.com/2013/02/asm-js.html
    • _bxg1 7y ago
      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.
      • erikpukinskis 7y ago
        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.
      • XCSme 7y ago
        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.
  • WorldMaker 7y ago
• giancarlostoro 7y ago
  I'm waiting to hear about when they start to rewrite their JS interpreter in Rust. It will make things kind of interesting, especially if it becomes a stand-alone capable JS inrepreter.
  • oscargrouch 7y ago
    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 technique used by LuaJIT before with great success). By the way lets not forget we are talking about Mozilla here, were a couple of more misguided projects could mean the abrupt end of the organization who is suffering to keep its market share in the browser wars. There are a couple of things that could take some advantage for being re-coded in Rust, but modern super-powered javascript VM´s are hardly one of those things. Of course, if in the sidelines someone craft a JS VM in Rust, and after IDK, 4 years, you have a mature enough JIT VM, maybe there will be a reason to move, but Mozilla itself investing its unsustainable, limited and in the brink of extinction funds on something that will require a lot of money and that in the end will get you basically the same perfomance as the old C++ jit, its a pretty bad move.
    • giancarlostoro 7y ago
      There's already a JIT for JS coded in Rust: https://blog.mozilla.org/javascript/2017/10/20/holyjit-a-new-hope/ https://blog.mozilla.org/javascript/2017/10/20/holyjit-a-new... The overall goal is to have Firefox recoded in Rust, why would a JavaScript interpreter be left out? https://wiki.mozilla.org/Oxidation https://wiki.mozilla.org/Oxidation That's the whole point of Oxidation.
      • oscargrouch 7y ago
        Of course they can do it. I just dont think is a clever move for them to do it. Firefox is having a hard time to compete with Chrome, and they took too long pursuing other goals, and just remembering one key feature they took a lot of time to implement, was making Firefox a the multi-process browser as Chrome. I mean, you would be ditching all this effort, rewriting it in Rust, spending key resources only to have some parity with the same browser you already had in C++, spending years, and loosing more market share, as Chrome can spend this time in optimization and features. For the record, i think Rust is what will save Mozilla, but it must reinvent itself. Do the best they can with the firefox codebase they have, and use Rust for new projects. Like, creating Cloud, backend system software, and reinvent itself like Ubuntu is doing right now. They have to be very strategic and pragmatic right now. Two big moonshots, Firefox OS and Rust, and only one of them has paid out their time and resources. If they want to bet in more moonshots, great, but they must do it in "blue ocean" places, being more innovative on where they should use Rust, were Rust can shine. I just think that from a strategic (and even technical) point of view, they are just spending precious resources, while at the same time eroding even more their browser market share.
• the8472 7y ago
  That sounds like the opposite of what graal+truffle is doing. With truffle you write an interpreter and graal specializes it into a JIT.
• gwern 7y ago
  So would this be one of the Futamura projections http://blog.sigfpe.com/2009/05/three-projections-of-doctor-futamura.html http://blog.sigfpe.com/2009/05/three-projections-of-doctor-f... ?
• eternalny1 7y ago
  > Baseline JIT compilation is fast, but modern web applications like Google Docs or Gmail execute so much JavaScript code that we could spend quite some time in the Baseline compiler, compiling thousands of functions. Good read. The above mentioned web apps are my biggest pain point at the moment with Firefox. I still use Gmail in Firefox, but it's much slower than running it on chromium. I just accept that, since Google makes all of that. However, with Google Docs I actually switch over to a chromium browser, even the new Edge beta, because it is simply too slow in Firefox. It looks like they've taken notice of that and are tackling it head on. Excellent work!
• pizlonator 7y ago
  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 this for JS). It's weird that they kept the C++ interpreter. But not too weird, if the IC logic in the new interpreter is costly. In the LLInt, the IC/type logic is either a win (ICs are always a win) or neutral (value profiling and case flag profiling costs nothing in LLInt). Also worth noting that this architecture - a JIT ABI interpreter that collects types as a bottom tier - is older than any JS engine. I learned it from HotSpot, and I guess that design was based on a Strongtalk VM. This is the current state of the art of JSC's bottom interpreter tier FWIW: https://webkit.org/blog/9329/a-new-bytecode-format-for-javascriptcore/ https://webkit.org/blog/9329/a-new-bytecode-format-for-javas...
  • The_rationalist 7y ago
    Are there any solid benchmarck comparing JSC vs v8?
    • Mathnerd314 7y ago
      I found https://webkit.org/blog/8685/introducing-the-jetstream-2-benchmark-suite/ https://webkit.org/blog/8685/introducing-the-jetstream-2-ben..., with a graph at the end, but of course that is written by Webkit (JSC) developers. Then there is https://johnresig.com/blog/javascript-performance-rundown/ https://johnresig.com/blog/javascript-performance-rundown/ from 2008. https://www.railsmine.net/2017/12/browser-benchmark-safari-11-chrome-63-firefox-57.html https://www.railsmine.net/2017/12/browser-benchmark-safari-1... from 2017, similar results to the JetStream 2 post.
    • pizlonator 7y ago
      JSC has had a set of large metabenchmarks like JetStream2 for a while. We have been the fastest for a while but V8 is gaining, so the current advantage is significant but not earth shattering. The last time V8 had their own benchmark, they retired it right after we beat them on it and made a post saying that benchmarks are bad because people cheat on them. Around that time I stopped seeing google.com claim that I should switch to Chrome “because it’s faster”. So basically JSC is fast enough to have made V8 ragequit benchmarking. Hope that answers your question!
• sehugg 7y ago
  What's a good way to diagnose optimzation/deoptimization performance issues? The Z80 emulator I use for http://8bitworkshop.com/ 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)
  • tasty_freeze 7y ago
    I have written a single javascript program in my life, and it was an emulator for an 8080-based machine. I used https://bluishcoder.co.nz/js8080/ https://bluishcoder.co.nz/js8080/ for that part of the emulator, though I had to make some changes to it. I found the emulator ran 4x faster on firefox than on chrome. The culprit was the main dispatch loop, a 256-entry switch statement. Chrome used a slow fall-back path because there were too many cases. The fix was to have "if (opcode < 128) { switch for first 128 cases} else { switch for other 128 cases }". It made FF a little bit slower, but greatly sped up on Chrome. I also tried generating 256 functions and then dispatch to the right sub based on an array of function pointers, but it wasn't any faster than the switch statement. But that was five year ago, and I'm sure the landscape is different now.
• bumblebritches5 7y ago
  tl;dr: Mozilla has finally put in the effort to multithread their javascript interpreter yet they misattribute the speedup to their language of choice.
• opan 7y ago
  I'm seeing a lot of people saying gmail and youtube are slow in Firefox. This may not sound like a good answer, but consider using a dedicated video player such as mpv for youtube, and an email client instead of webmail. Web browsers are some of the worst-performing software we have today. Asking them to do more than display documents and web pages never seems to go well.
• tom_mellior 7y ago
  The idea of generating an interpreter from the compiler is really neat. What I missed in this article is why the Baseline Interpreter is faster than the C++ interpreter. The code snippet for the load zero instruction looks like what a compiler should produce for a straightforward C++ switch case for that instruction. Except that the code uses a push instruction to store the value directly on the system stack, whereas the C++ interpreter would presumably use a more general store instruction into an array (in the heap, maybe) treated as the interpreter stack. Is that the difference, or am I missing something else?
  • mattnewport 7y ago
    The article called it a threaded interpreter, the answer to this question explains what that usually means and why it it faster: https://stackoverflow.com/questions/3848343/decode-and-dispatch-interpretation-vs-threaded-interpretation https://stackoverflow.com/questions/3848343/decode-and-dispa... I found the explanation of what they're doing a little unclear though and it seems they might not be doing exactly what is described in the answer above.
    • tom_mellior 7y ago
      The dispatch part of the code snippet looks to me like what you would also get with computed gotos. Something like goto instruction_labels[++pc]. So that shouldn't be the difference, compilers can compile this well. As for whether this is "threaded", and exactly what kind of threading it is, there is widespread confusion and abuse of terminology. https://en.wikipedia.org/wiki/Threaded_code https://en.wikipedia.org/wiki/Threaded_code
  • jandem 7y ago
    > Is that the difference, or am I missing something else? That's part of it. The generated interpreter should be a bit faster for simple instructions because of the reason you give (also: things like debugger breakpoints have more overhead in the C++ Interpreter). However, the bigger speedups are because the generated interpreter can use Inline Caches like the Baseline JIT. The C++ Interpreter does not have ICs.
• Noumenon72 7y ago
  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?
  • lovasoa 7y ago
    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.
• FreeHugs 7y ago
  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 load code when it is needed in modern Javascript: let calendar = await import('/modules/calendar.js'); calendar.askUserForDay("Checkin Date");
  • rocqua 7y ago
    You are possibly right, but it would be sad if we our choices for writing programs with a UI are: write in javascript or compile to javascript. There are many languages out there, webASM would allow them to work without the massive pain of cross-compilation. I guess I am just an idealist screaming about how packet switched networks are unreliable and we should all use circuit switched networks.
    • FreeHugs 7y ago
      If you want to use a different language, why would you care about the compile target? Compiling is done by the compiler. So to the developer it is the same. No matter if it comiles to Javascript or Webassembly. In the end, I don't think writing code for the web in languages other then Javascript will take off. Simply because Javascript will always evolve to fit this specific environment. And therefore will always be the best choice. While other languages will evolve to be the best fit for their niche.
      • rocqua 7y ago
        Cross compilation always comes at a performance cost. Moreover, it is another compilation target your compiler needs to support. When that compilation target is a high-level language, supporting it is harder. This means java-script as a compilation target is less likely to be added.
      • pjmlp 7y ago
• needle0 7y ago
  I'm using Firefox for pretty much everything including Google apps, but the one thing I do wish Firefox had is support for casting via Chromecast. In my experience, Chromecast support has been sorta spotty even on Chromium-based browsers like Vivaldi or Brave, forcing me to keep Chrome proper installed on my PC for when I want to cast a YouTube video onto a bigger screen. Is this bit of functionality too proprietary or entrenched enough that it cannot be ported to any non-Chromium browser?
  • alex7o 7y ago
    You can use VLC to Chromecast, it is a little bit fiddly but it works most of the time.
• ledauphin 7y ago
  I've switched to Firefox 3 times in the last 2 years, and each time I've been forced back to Chrome by horrendously (2-3x worse) bad battery life on my MacBook, caused by some variant of this bug which Mozilla seems determined not to fix. https://bugzilla.mozilla.org/show_bug.cgi?id=1404042 https://bugzilla.mozilla.org/show_bug.cgi?id=1404042
  • opencl 7y ago
    What makes you think they're determined not to fix it? A commit that significantly improves the situation landed in nightly a week ago. https://bugzilla.mozilla.org/show_bug.cgi?id=1429522 https://bugzilla.mozilla.org/show_bug.cgi?id=1429522
    • ledauphin 7y ago
      the fact that they've not fixed it for literally years, despite having hundreds or thousands of reports? I'll believe they have a fix when I see it with my own eyes, which probably won't be for another 6 months because switching my browser workflow isn't something I want to do every couple of weeks to try out a new nightly with big promises.
• dandigangi 7y ago
  Had no idea their interpreter was C++ under the hood. Excellent article fro the Mozilla team as always.