Crypto miners written in JS existed long before WebAssembly. Back then people also compiled large C++ code bases to (highly obfuscated) JS code and out of these heroic efforts grew asm.js which then evolved to WebAssembly. WebAssembly is a much better compile target than JS with more low-level types and primitives, but it's very similar to JS code in what it can and can't do in the browser.
Compiling a C++ application to megabytes of JS code doesn't make the result any more open-source or non-DRM than compiling the same thing to WebAssembly (you could translate Wasm to the equivalent but slower JS code).
Nice to hear from you! Yes it was a very reasonable choice back then, before (enormous) asm.js and Wasm functions.
The compiler wasn't really designed for these huge graphs, but fortunately a lot of the issues can be fixed incrementally and it's still holding up well.
I think part of this is just time to get used to something new? You might notice some improvements too, for instance only after I started using Fastmail I realized the Gmail UI can be pretty slow and heavyweight although I never noticed this before.
> With Fastmail or another provider, you're trusting another corp.
You're trusting a corp that offers customer support, a service you pay them for. With Gmail you're completely on your own because you're only a small cog in the massive data mining machine. That's a pretty big difference.
That said, it's a good idea to set up a custom domain with a trusted registrar.
I migrated to Fastmail a few weeks ago. I'm really happy with it and I wish I had done it years ago. Many features. The web interface and apps feel a lot faster than Gmail.
Pro-tip: use a custom domain so that you can easily switch e-mail providers in the future without vendor lock-in. It's also very easy to add aliases in Fastmail.
> Plus after the import is finished, it will still periodically bring over any new emails received to the Gmail account.
Another option is to let Gmail forward your email to the new address.
> It’s a big deal and everyone who contributed should be super proud.
Thanks! We actually haven't really analyzed Speedometer (and most other benchmarks) yet with Warp so I expect this number to improve the coming months. The design seems to be holding up well and we're really excited about building on this.
SpiderMonkey dev here. Does this reproduce for you with a clean profile? Because I just tried this with 78.0b9 too and for the first one, Local (original), I get 6.7 ms in the Web Console, very similar to what I see in Chrome. I didn't look at the other ones.
> They all looked glum, and said "There is no alternative".
Most people that I know here in the Netherlands prepare lunch at home and bring it to work or school. I work from home now and still usually eat simple sandwiches for lunch so at least for me it's not about "no alternatives".
It gives me more time to go outside or stop working early - I honestly don't want to spend (at least) an hour going out just to have lunch and then a similar ritual in the evening for dinner.
> 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.
> 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.