24 ms·

Making JavaScript run fast on WebAssembly

215 points by 0xedb 5y ago

nielsbot 5y ago
Reminds of Omega--you wrote scripts to operate autonomous tanks, and pitted your tanks against others' in an obstacle-filled arena. Omega didn't have the realtime scripting component though. https://en.wikipedia.org/wiki/Omega_(video_game) https://en.wikipedia.org/wiki/Omega_(video_game)
- TchoBeer 5y ago
  Wrong thread?
  - nielsbot 5y ago
    yup. thanks.
- jagged-chisel 5y ago
  I think you wanted https://news.ycombinator.com/item?id=27365961 https://news.ycombinator.com/item?id=27365961
  - nielsbot 5y ago
    thanks.
kodablah 5y ago
> So how does this work? Before the code is deployed, as part of a build step, we run the JS code using the JS engine to the end of initialization. I also did basically this exact same thing for Go [0] when I realized their initialization in WASM was very heavy[1]. Basically I ran up until the real Go main started which includes a ton of runtime package/data initialization, and took a snapshot of the data and baked it back into the WASM and removed all the pre-main code. Granted this was years ago so I don't know if it still works on generated code today, but the idea is the same. I think languages compiling to WASM, if they can, should run their initialization code and snapshot the data. A lot of people don't realize the number of init instructions to bootstrap a runtime these days. Go alone has thousands of instructions just to initialize the unicode tables. Over 4 million instructions before main were removed from hello-world Go WASM init by pre-processing. 0 - https://github.com/cretz/go-wasm-bake https://github.com/cretz/go-wasm-bake 1 - https://github.com/golang/go/issues/26622 https://github.com/golang/go/issues/26622
- skratlo 5y ago
  And round and round we go http://www.sbcl.org/manual/index.html#Saving-a-Core-Image http://www.sbcl.org/manual/index.html#Saving-a-Core-Image
  - deathanatos 5y ago
    Which reminds me of Emac's unexec(): https://emacshorrors.com/posts/unexecute.html https://emacshorrors.com/posts/unexecute.html (Not sure if that's the best link, but it is easily Googleable.)
    - mananaysiempre 5y ago
      “Format compilation” in TeX also appears to be inspired by a similar snapshotting mechanism built into TOPS-20[1]. Generally, I’d say that dumping VM state (if not in the host executable format) is a perfectly ordinary thing for an isolated VM to do. It’s the default way Smalltalk systems operate, for example, being very close ideologically to Lisp machines in that they try to be an OS centered around a programming language more than a programming language implemented inside an OS. (I should really look into that Oberon thing one of those days...) [1]: https://tug.org/TUGboat/tb26-1/beebe.pdf https://tug.org/TUGboat/tb26-1/beebe.pdf
      - mananaysiempre 5y ago
        ... Aa-and I’m being stupid, because there were of course also “persistent” OSes like KeyKOS[1], where a memory image (swapped in, modified, and swapped out as necessary) is essentially the only way for a program to exist. (Good news: capability access control is easy to program to and has entirely intuitive dynamic behaviour. Bad news: noöne has worked out how to bootstrap this dynamic behaviour from a static set of rules in a reasonably modular way, to the point that making a system which can hibernate but never shut down actually starts to look like a reasonable solution.) [1]: http://cap-lore.com/CapTheory/upenn/ http://cap-lore.com/CapTheory/upenn/
  - tingletech 5y ago
jonny_eh 5y ago
I'm so lost. Why are you shipping a JS Engine built for WASM? Wouldn't any platform that can run WASM also run JS code?
- skratlo 5y ago
  They wants to run JS faster, on platforms where they can run Swift/native with zero overhead. As of why? Go figure.
  - lxgr 5y ago
    If you're talking about iOS, if you can run WASM, you can run JITted JavaScript. I highly doubt that it's possible to beat the performance of JavaScriptCode (in JIT mode) with any WASM-based implementation.
    - wffurr 5y ago
      Depends on whether your JS is limited by interpreter / JIT startup time or throughput. If it's the former, then the wasm module with wizer might be significantly faster.
  - gostsamo 5y ago
    Serverless is mentioned a few times in the text of the article. More generally, WASM is promoted as universal bytecode virtual machine, so they want to make it "run everything everywhere".
    - oscargrouch 5y ago
      I think WASM will have a great future in the cloud, giving cloud providers can offer their services in any programming language their users want, running in a secure sandbox. But i'm not so sure about personal devices. It would be very hard to beat Javascript code on the Web in general. So i dont know about the general purpose target future in that case, i think it will flop, except as a fancy accelerator or to virtualize things that was once outside the web.
fabrice_d 5y ago
Since they are working with SpiderMonkey (Firefox JS engine), I wonder if that opens the door to a Gecko based browser on iOS with decent enough performance. That would be a game changer!
- MaxBarraclough 5y ago
  No, that's forbidden by the App Store rules, with a possible exception where the HTML is supplied by the app itself rather than being downloaded. [0] From Section 2.5.6: > Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript. Also Section 4.7: > only uses capabilities available in a standard WebKit view (e.g. it must open and run natively in Safari without modifications or additional software) [0] https://developer.apple.com/app-store/review/guidelines/ https://developer.apple.com/app-store/review/guidelines/
  - oscargrouch 5y ago
    This is like a car company that also have a tire company, also providing the tires. So far so good, but the company that makes the car only allow you to use its own tire brand, no others are allowed. How legislators can easily spot problems in bad company practices that forces monopoly in material objects but are so obnoxious to everything digital? I see even tech veterans here struggling in seeing that there's a big problem in all this.. Its like Microsoft not only shipping IE with windows, but making web sites slow in other browsers on purpose so at least in Windows nobody would use the IE competitors. Why Apple is getting away for more than 10 years to such shady practices is beyond comprehension. And this is just one of them.
    - pjmlp 5y ago
      Market share, that is how.
  - sojuz151 5y ago
    You could create a website where you could browse the internet with a browser written in JS. No apple approval needed.
syrusakbary 5y ago
It should probably be named "Making JavaScript to startup fast on WebAssembly", since the runtime speed is not really improved by their approach. Besides that, I think Wizer [1] is both an elegant and a simple solution to speed up startup times with Wasm. So good work on that! [1] - https://github.com/bytecodealliance/wizer https://github.com/bytecodealliance/wizer
- topspin 5y ago
  "Making JavaScript to startup fast on WebAssembly" The original is at least grammatically correct.
  - syrusakbary 5y ago
    I'm not a native english speaker, so some of my grammar mistakes are due to that! How would you have written it?
    - slavik81 5y ago
      Either "Making JavaScript startup fast on WebAssembly" or "Making JavaScript fast to startup on WebAssembly".
    - topspin 5y ago
      Omit "to" and it's ok. Making -> Make isn't a bad idea either, as a headline.
richdougherty 5y ago
Here's the talk related to the article: https://www.youtube.com/watch?v=C6pcWRpHWG0 https://www.youtube.com/watch?v=C6pcWRpHWG0 > Nick Fitzgerald — Hit the Ground Running: Wasm Snapshots for Fast Startup > > Don't make your users wait while your Wasm module initializes itself! Wizer instantiates your WebAssembly module, executes its initialization functions, and then snapshots the initialized state out into a new, pre-initialized WebAssembly module. Now you can use this new module to hit the ground running, without waiting for any of that first-time initialization code to complete. This talk will cover the design and implementation of Wizer; discuss its performance characteristics and the scenarios in which it excels and when it isn't the right tool; and finally, in the process of doing all that, we'll take a closer look at what makes up the guts of a WebAssembly module: memories, globals, tables, etc. Lots of interesting talks at the recent WebAssembly Summit! https://2021.webassembly-summit.org/ https://2021.webassembly-summit.org/
- chrisseaton 5y ago
  Sounds a lot like how GraalVM runs Java applications to the point where they're initialised and then compiles them to native code.
xkyf 5y ago
Run quickly*
neonate 5y ago
https://archive.is/CHqkM https://archive.is/CHqkM https://web.archive.org/web/20210602191646/https://bytecodealliance.org/articles/making-javascript-run-fast-on-webassembly https://web.archive.org/web/20210602191646/https://bytecodea...
lyptt 5y ago
I find it interesting they compiled SpiderMonkey to WASM to run JS in its interpreter mode when it already has iOS support built-in via the interpreter. I would've thought all of the performance enhancements could be done without involving WASM at all. As far as I'm aware the only reason why Firefox for iOS doesn't use SpiderMonkey is App Store restrictions.
- wffurr 5y ago
  The wizer approach to reducing JS interpreter startup time can't work with the iOS built-in interpreter.
rektide 5y ago
I'm mostly overwhelmed by excitement & fascination. An amazing effort. Three little notes jump out at me, first: > WebAssembly doesn’t allow you to dynamically generate new machine code and run it from within pure Wasm code. This is a surprise to me. For some reason I thought wasm code could be a SharedArrayBuffer. And I thought that would be mutable. You might maybe have to round trip back to JS to modify this? But I thought it was read-write. I'm probably wrong but this was quite a surprise to me & a bit of a shocker to hear! Although there's good security things you get from this, I didn't expect it to be hard set. Second thing that jumps out at me is a little fear. I look at the various projects out there intent on replacing the common DevTools debuggable/extension-able web page with a bunch of animated pixels, via use of Canvas, like Google's CanvasKit renderer for Flutter. To me, this is scary territory, because it de-empowers the user. This project here has uses far beyond the web, that's it's real purpose I think (who wants to load the spidermonkey engine compiled to wasm to start running their js on their site), but it still just makes me a little scared of the common DevTools experience fracturing & shattering, into many pieces. This project isn't uniquely scary, versus Go on WASM, or Rust on WASM, but it's still something I'm nervous about, and this article made me think of how easy it would be to start making the JS we run considerably harder to wrangle by people writing extensions or enhancing their user agent. Third, > Because the JS engines used to create isolates are large codebases, containing lots of low-level code doing ultra-complicated optimizations, it’s easy for bugs to be introduced that allow attackers to escape the VM and get access to the system the VM is running on. Color me a little skeptical about the virtue of adding another security layer into the virtual machine. I really hope we can get good at isolates, to build blisteringly fast systems, and that we don't need to have multiple (or sometimes 1) processes on a computer, each running multiple isolates, each running multiple wasm containers. It's a cool capability, but I feel like ideally we'd be better off with less levels of nesting to get down to the real "process" (process->isolate->wasm-container), & better able to trust & leverage & use isolates really well to sandbox work. It seems to be working very very well for those with neat edge tech like CloudFlare Workers. That said, I just did a quick search & a year ago someone was saying V8 isolates take ~3MB of memory each, which is far from insignificant. Developing AOT js->wasm tech could potentially have a huge memory-saving benefit. Ah, ok, good, the lightweight nature of wizer'ed containers is emphasized fairly well in this post! It didn't leap out at me the first time but it's definitely there! This is the core possible advantage, besides simply enabling better exploration of the problem space, which is also key. Fourth, > We started with making initialization fast with a tool called Wizer. I’m going to explain how, but for those who are impatient, here’s the speed up we see when running a very simple JS app. This is a huge focus of this post, and it's a great technical marvel. On the other hand, the post talks about the advantages of how Wizer can use snapshots to skip initialization & start with a pre-booted application... the thing is: v8 Isolates can do that too. Deno has been doing quite a lot of work figuring out how to wrangle & manage & make effective use of V8 Isolates snapshots, for example, and that's one of the core reasons I think it is an impressively promising advancement & upcoming core technology. Deno is really trying to wrap & better expose the V8 runtime in a better managed fashion, and I think we'll see many of the advantages claimed by Wizer start to get reported out the world via Deno as well, over time.
mamcx 5y ago
This sound tempting.. I'm building an interpreter (https://tablam.org https://tablam.org) ad one of the reason is the interpreters are better for exploration/repls and such. This looks like it will fix a major point: I could compile everything that is typed and left the rest for runtime. I'm wondering how much easier could be the life if I compile to WASM to be run on my host...
baybal2 5y ago
WASM is slowly, and inevitably becoming Java 2.0, or better to say a new Java VM sans Java.
- emteycz 5y ago
  Yes, that is more or less the goal - with the major difference being cross-industry collaboration - every major player is included and even the community has its word.
  - kaba0 5y ago
    How is the JEP process not cross-industry collaboration with a significant community voice?
    - k__ 5y ago
      Didn't the Harmony disaster show that Java is a garbage fire?
      - kaba0 5y ago
        If you mean the Oracle v Google fiasco, it was a legal battle on whether it is legal to copy a significant part but not exactly the whole of what is called JavaTM. But Java is one of the few major languages that is standard-specified, not specified by the reference implementation, the reference impl. is completely open source, and the ecosystem is blooming. So, no? It is a huge platform running a very very significant chunk of all the backend servers.
        emteycz 5y ago
        Exactly - while Wasm is meant to be much lighter and free of backwards compatibility, and thus hopefully actually safe
        kaba0 5y ago
hsbauauvhabzb 5y ago
As someone who will shortly need to do two very compute intensive functions in the browser (filtering large datasets (100k+ rows) via client specified queries, and parsing large sting blobs) what is my best option? I’m aware of server side rendering but I suspect the performance in the client may be better responsiveness, with a failover to the server if it’s faster to provide a query response, but is there anything I should _really_ consider for client JS performance at that level?
- ficklepickle 5y ago
  A WebWorker can free up the main thread so the UI doesn't grind to a halt. Unfortunately they might not help you here. Data in/out of the worker is string only[0], so the extra parsing/serializing usually ruins any perf benefit. You can access indexedDB from the worker, though. So you load the DB from the main thread, then you can do the filtering from the worker. You could return indexes then fetch those from indexDB on the main thread. None of this will help with parsing large strings though, you are probably stuck with doing that on the main thread. And it is also not going to reduce the total time to perform the work. But hopefully it will avoid pinning the main thread, because that is bad. I really enjoy this stuff, so feel free to contact me if you wanna talk it through. My email address is in my profile. [0] SharedArrayBuffers were recently re-enabled according to https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - markdog12 5y ago
    > Data in/out of the worker is string only[0] I don't think this is correct. You can pass lots of types in via postMessage(), including Objects, ArrayBuffers, even a Canvas context. Some objects are transferrable as well, that is, zero copy. As far as your point about still being stuck on the main thread, that may indeed be the case depending on the work. More info: https://stackoverflow.com/questions/19152772/how-to-pass-large-data-to-web-workers https://stackoverflow.com/questions/19152772/how-to-pass-lar...
  - hsbauauvhabzb 5y ago
merb 5y ago
btw. this could also be interesting for spa applications that do not use node.js on the backend. I wonder when there will be code examples. I would really want to look more into spidermonkey+js in wasm and trying to get spa output.
vsroy 5y ago
I think the fact that you can save WASM memory / state will yield itself for very powerful applications in the future. I think there's a world where true time-travel debugging is possible because you execute your Python program inside of a WASM VM & with WASM, you can save the memory/local registers/etc. and do true backwards/forwards execution.
- vlovich123 5y ago
  Is there any reason to believe that this will be faster or more powerful than how reverse debugging works today? rr is already pretty fantastic and handles pretty complex cases surprisingly well with decent performance. I believe the way it works is that it only records memory changes of side-effect APIs (I.e. I/O, kernel, etc) & then just runs the program instruction backwards between those points. I’m not sure that snapshotting the entire RAM for an application will prove to be more efficient/powerful (copying large amounts of RAM is generally expensive). You might try to do crazy tricks like making the pages COW (while flushing them to disk) to reduce the actual cost of how many pages need to be copied. I think that’s still tough to compete with vs just recording the little bit of state around function calls that have side effects.
  - miloignis 5y ago
    I've contemplated building a reverse debugger for wasm - rr is amazing, but frustrates me with touchy dependence on hardware features (sometimes doesn't work in a VM, doesn't support some CPUs, etc) and lack of ability to fork the timeline. I'd love to be able to backup, change a variable, and then proceed forwards - tree style undo and redo, as it were.
    - vlovich123 5y ago
      I haven’t tried but I’m pretty sure you can change variable values. Aside from it being Linux-only I haven’t encountered the CPU challenges. VM incompatibilities are a different story as I generally only ever run directly on metals when debugging. That being said, it looks like it does work (at least if you have sufficiently new software bits) so may be worth giving it another go: https://github.com/rr-debugger/rr/issues/2806 https://github.com/rr-debugger/rr/issues/2806
sandstrom 5y ago
I wonder if the new Wizer component can be used by other projects in the WebAssembly space, e.g. Wasmer? https://github.com/wasmerio/wasmer https://github.com/wasmerio/wasmer (Haven't fully grasped how they're different from wasmtime, but I think they've spend more effort on embedding the runtime into other languages)
ficklepickle 5y ago
I'm hoping this will be useful for improving react native performance on iOS. Due to restrictions on that platform the JS is currently interpreted and performance is terrible.
saagarjha 5y ago
Oh, interesting, it looks like Lin Clark is now at Fastly. I knew I recognized tho at art style…
skilesare 5y ago
If anyone out there is involved with this I am very interested and very motivated to figure out if I can get a JavaScript engine running in a DFINITY canister. I just need a compiled wasm and a candid file to try it out. I think. The wasm might need to be compiled in a particular way.

215 points by 0xedb 5y ago

Reminds of Omega--you wrote scripts to operate autonomous tanks, and pitted your tanks against others' in an obstacle-filled arena. Omega didn't have the realtime scripting component though. https://en.wikipedia.org/wiki/Omega_(video_game) https://en.wikipedia.org/wiki/Omega_(video_game)

TchoBeer 5y ago
Wrong thread?
- nielsbot 5y ago
  yup. thanks.
jagged-chisel 5y ago
I think you wanted https://news.ycombinator.com/item?id=27365961 https://news.ycombinator.com/item?id=27365961
- nielsbot 5y ago
  thanks.

kodablah 5y ago

> So how does this work? Before the code is deployed, as part of a build step, we run the JS code using the JS engine to the end of initialization. I also did basically this exact same thing for Go [0] when I realized their initialization in WASM was very heavy[1]. Basically I ran up until the real Go main started which includes a ton of runtime package/data initialization, and took a snapshot of the data and baked it back into the WASM and removed all the pre-main code. Granted this was years ago so I don't know if it still works on generated code today, but the idea is the same. I think languages compiling to WASM, if they can, should run their initialization code and snapshot the data. A lot of people don't realize the number of init instructions to bootstrap a runtime these days. Go alone has thousands of instructions just to initialize the unicode tables. Over 4 million instructions before main were removed from hello-world Go WASM init by pre-processing. 0 - https://github.com/cretz/go-wasm-bake https://github.com/cretz/go-wasm-bake 1 - https://github.com/golang/go/issues/26622 https://github.com/golang/go/issues/26622

skratlo 5y ago
And round and round we go http://www.sbcl.org/manual/index.html#Saving-a-Core-Image http://www.sbcl.org/manual/index.html#Saving-a-Core-Image
- deathanatos 5y ago
  Which reminds me of Emac's unexec(): https://emacshorrors.com/posts/unexecute.html https://emacshorrors.com/posts/unexecute.html (Not sure if that's the best link, but it is easily Googleable.)
  - mananaysiempre 5y ago
    “Format compilation” in TeX also appears to be inspired by a similar snapshotting mechanism built into TOPS-20[1]. Generally, I’d say that dumping VM state (if not in the host executable format) is a perfectly ordinary thing for an isolated VM to do. It’s the default way Smalltalk systems operate, for example, being very close ideologically to Lisp machines in that they try to be an OS centered around a programming language more than a programming language implemented inside an OS. (I should really look into that Oberon thing one of those days...) [1]: https://tug.org/TUGboat/tb26-1/beebe.pdf https://tug.org/TUGboat/tb26-1/beebe.pdf
    - mananaysiempre 5y ago
      ... Aa-and I’m being stupid, because there were of course also “persistent” OSes like KeyKOS[1], where a memory image (swapped in, modified, and swapped out as necessary) is essentially the only way for a program to exist. (Good news: capability access control is easy to program to and has entirely intuitive dynamic behaviour. Bad news: noöne has worked out how to bootstrap this dynamic behaviour from a static set of rules in a reasonably modular way, to the point that making a system which can hibernate but never shut down actually starts to look like a reasonable solution.) [1]: http://cap-lore.com/CapTheory/upenn/ http://cap-lore.com/CapTheory/upenn/
- tingletech 5y ago

jonny_eh 5y ago

I'm so lost. Why are you shipping a JS Engine built for WASM? Wouldn't any platform that can run WASM also run JS code?

skratlo 5y ago
They wants to run JS faster, on platforms where they can run Swift/native with zero overhead. As of why? Go figure.
- lxgr 5y ago
  If you're talking about iOS, if you can run WASM, you can run JITted JavaScript. I highly doubt that it's possible to beat the performance of JavaScriptCode (in JIT mode) with any WASM-based implementation.
  - wffurr 5y ago
    Depends on whether your JS is limited by interpreter / JIT startup time or throughput. If it's the former, then the wasm module with wizer might be significantly faster.
- gostsamo 5y ago
  Serverless is mentioned a few times in the text of the article. More generally, WASM is promoted as universal bytecode virtual machine, so they want to make it "run everything everywhere".
  - oscargrouch 5y ago
    I think WASM will have a great future in the cloud, giving cloud providers can offer their services in any programming language their users want, running in a secure sandbox. But i'm not so sure about personal devices. It would be very hard to beat Javascript code on the Web in general. So i dont know about the general purpose target future in that case, i think it will flop, except as a fancy accelerator or to virtualize things that was once outside the web.

fabrice_d 5y ago

Since they are working with SpiderMonkey (Firefox JS engine), I wonder if that opens the door to a Gecko based browser on iOS with decent enough performance. That would be a game changer!

MaxBarraclough 5y ago
No, that's forbidden by the App Store rules, with a possible exception where the HTML is supplied by the app itself rather than being downloaded. [0] From Section 2.5.6: > Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript. Also Section 4.7: > only uses capabilities available in a standard WebKit view (e.g. it must open and run natively in Safari without modifications or additional software) [0] https://developer.apple.com/app-store/review/guidelines/ https://developer.apple.com/app-store/review/guidelines/
- oscargrouch 5y ago
  This is like a car company that also have a tire company, also providing the tires. So far so good, but the company that makes the car only allow you to use its own tire brand, no others are allowed. How legislators can easily spot problems in bad company practices that forces monopoly in material objects but are so obnoxious to everything digital? I see even tech veterans here struggling in seeing that there's a big problem in all this.. Its like Microsoft not only shipping IE with windows, but making web sites slow in other browsers on purpose so at least in Windows nobody would use the IE competitors. Why Apple is getting away for more than 10 years to such shady practices is beyond comprehension. And this is just one of them.
  - pjmlp 5y ago
    Market share, that is how.
- sojuz151 5y ago
  You could create a website where you could browse the internet with a browser written in JS. No apple approval needed.

syrusakbary 5y ago

It should probably be named "Making JavaScript to startup fast on WebAssembly", since the runtime speed is not really improved by their approach. Besides that, I think Wizer [1] is both an elegant and a simple solution to speed up startup times with Wasm. So good work on that! [1] - https://github.com/bytecodealliance/wizer https://github.com/bytecodealliance/wizer

topspin 5y ago
"Making JavaScript to startup fast on WebAssembly" The original is at least grammatically correct.
- syrusakbary 5y ago
  I'm not a native english speaker, so some of my grammar mistakes are due to that! How would you have written it?
  - slavik81 5y ago
    Either "Making JavaScript startup fast on WebAssembly" or "Making JavaScript fast to startup on WebAssembly".
  - topspin 5y ago
    Omit "to" and it's ok. Making -> Make isn't a bad idea either, as a headline.

richdougherty 5y ago

Here's the talk related to the article: https://www.youtube.com/watch?v=C6pcWRpHWG0 https://www.youtube.com/watch?v=C6pcWRpHWG0 > Nick Fitzgerald — Hit the Ground Running: Wasm Snapshots for Fast Startup > > Don't make your users wait while your Wasm module initializes itself! Wizer instantiates your WebAssembly module, executes its initialization functions, and then snapshots the initialized state out into a new, pre-initialized WebAssembly module. Now you can use this new module to hit the ground running, without waiting for any of that first-time initialization code to complete. This talk will cover the design and implementation of Wizer; discuss its performance characteristics and the scenarios in which it excels and when it isn't the right tool; and finally, in the process of doing all that, we'll take a closer look at what makes up the guts of a WebAssembly module: memories, globals, tables, etc. Lots of interesting talks at the recent WebAssembly Summit! https://2021.webassembly-summit.org/ https://2021.webassembly-summit.org/

chrisseaton 5y ago
Sounds a lot like how GraalVM runs Java applications to the point where they're initialised and then compiles them to native code.

xkyf 5y ago

Run quickly*

neonate 5y ago

https://archive.is/CHqkM https://archive.is/CHqkM https://web.archive.org/web/20210602191646/https://bytecodealliance.org/articles/making-javascript-run-fast-on-webassembly https://web.archive.org/web/20210602191646/https://bytecodea...

lyptt 5y ago

I find it interesting they compiled SpiderMonkey to WASM to run JS in its interpreter mode when it already has iOS support built-in via the interpreter. I would've thought all of the performance enhancements could be done without involving WASM at all. As far as I'm aware the only reason why Firefox for iOS doesn't use SpiderMonkey is App Store restrictions.

wffurr 5y ago
The wizer approach to reducing JS interpreter startup time can't work with the iOS built-in interpreter.

rektide 5y ago

I'm mostly overwhelmed by excitement & fascination. An amazing effort. Three little notes jump out at me, first: > WebAssembly doesn’t allow you to dynamically generate new machine code and run it from within pure Wasm code. This is a surprise to me. For some reason I thought wasm code could be a SharedArrayBuffer. And I thought that would be mutable. You might maybe have to round trip back to JS to modify this? But I thought it was read-write. I'm probably wrong but this was quite a surprise to me & a bit of a shocker to hear! Although there's good security things you get from this, I didn't expect it to be hard set. Second thing that jumps out at me is a little fear. I look at the various projects out there intent on replacing the common DevTools debuggable/extension-able web page with a bunch of animated pixels, via use of Canvas, like Google's CanvasKit renderer for Flutter. To me, this is scary territory, because it de-empowers the user. This project here has uses far beyond the web, that's it's real purpose I think (who wants to load the spidermonkey engine compiled to wasm to start running their js on their site), but it still just makes me a little scared of the common DevTools experience fracturing & shattering, into many pieces. This project isn't uniquely scary, versus Go on WASM, or Rust on WASM, but it's still something I'm nervous about, and this article made me think of how easy it would be to start making the JS we run considerably harder to wrangle by people writing extensions or enhancing their user agent. Third, > Because the JS engines used to create isolates are large codebases, containing lots of low-level code doing ultra-complicated optimizations, it’s easy for bugs to be introduced that allow attackers to escape the VM and get access to the system the VM is running on. Color me a little skeptical about the virtue of adding another security layer into the virtual machine. I really hope we can get good at isolates, to build blisteringly fast systems, and that we don't need to have multiple (or sometimes 1) processes on a computer, each running multiple isolates, each running multiple wasm containers. It's a cool capability, but I feel like ideally we'd be better off with less levels of nesting to get down to the real "process" (process->isolate->wasm-container), & better able to trust & leverage & use isolates really well to sandbox work. It seems to be working very very well for those with neat edge tech like CloudFlare Workers. That said, I just did a quick search & a year ago someone was saying V8 isolates take ~3MB of memory each, which is far from insignificant. Developing AOT js->wasm tech could potentially have a huge memory-saving benefit. Ah, ok, good, the lightweight nature of wizer'ed containers is emphasized fairly well in this post! It didn't leap out at me the first time but it's definitely there! This is the core possible advantage, besides simply enabling better exploration of the problem space, which is also key. Fourth, > We started with making initialization fast with a tool called Wizer. I’m going to explain how, but for those who are impatient, here’s the speed up we see when running a very simple JS app. This is a huge focus of this post, and it's a great technical marvel. On the other hand, the post talks about the advantages of how Wizer can use snapshots to skip initialization & start with a pre-booted application... the thing is: v8 Isolates can do that too. Deno has been doing quite a lot of work figuring out how to wrangle & manage & make effective use of V8 Isolates snapshots, for example, and that's one of the core reasons I think it is an impressively promising advancement & upcoming core technology. Deno is really trying to wrap & better expose the V8 runtime in a better managed fashion, and I think we'll see many of the advantages claimed by Wizer start to get reported out the world via Deno as well, over time.

mamcx 5y ago

This sound tempting.. I'm building an interpreter (https://tablam.org https://tablam.org) ad one of the reason is the interpreters are better for exploration/repls and such. This looks like it will fix a major point: I could compile everything that is typed and left the rest for runtime. I'm wondering how much easier could be the life if I compile to WASM to be run on my host...

baybal2 5y ago

WASM is slowly, and inevitably becoming Java 2.0, or better to say a new Java VM sans Java.

emteycz 5y ago
Yes, that is more or less the goal - with the major difference being cross-industry collaboration - every major player is included and even the community has its word.
- kaba0 5y ago
  How is the JEP process not cross-industry collaboration with a significant community voice?
  - k__ 5y ago
    Didn't the Harmony disaster show that Java is a garbage fire?
    - kaba0 5y ago
      If you mean the Oracle v Google fiasco, it was a legal battle on whether it is legal to copy a significant part but not exactly the whole of what is called JavaTM. But Java is one of the few major languages that is standard-specified, not specified by the reference implementation, the reference impl. is completely open source, and the ecosystem is blooming. So, no? It is a huge platform running a very very significant chunk of all the backend servers.
      - emteycz 5y ago
        Exactly - while Wasm is meant to be much lighter and free of backwards compatibility, and thus hopefully actually safe
        kaba0 5y ago

hsbauauvhabzb 5y ago

As someone who will shortly need to do two very compute intensive functions in the browser (filtering large datasets (100k+ rows) via client specified queries, and parsing large sting blobs) what is my best option? I’m aware of server side rendering but I suspect the performance in the client may be better responsiveness, with a failover to the server if it’s faster to provide a query response, but is there anything I should _really_ consider for client JS performance at that level?

ficklepickle 5y ago
A WebWorker can free up the main thread so the UI doesn't grind to a halt. Unfortunately they might not help you here. Data in/out of the worker is string only[0], so the extra parsing/serializing usually ruins any perf benefit. You can access indexedDB from the worker, though. So you load the DB from the main thread, then you can do the filtering from the worker. You could return indexes then fetch those from indexDB on the main thread. None of this will help with parsing large strings though, you are probably stuck with doing that on the main thread. And it is also not going to reduce the total time to perform the work. But hopefully it will avoid pinning the main thread, because that is bad. I really enjoy this stuff, so feel free to contact me if you wanna talk it through. My email address is in my profile. [0] SharedArrayBuffers were recently re-enabled according to https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- markdog12 5y ago
  > Data in/out of the worker is string only[0] I don't think this is correct. You can pass lots of types in via postMessage(), including Objects, ArrayBuffers, even a Canvas context. Some objects are transferrable as well, that is, zero copy. As far as your point about still being stuck on the main thread, that may indeed be the case depending on the work. More info: https://stackoverflow.com/questions/19152772/how-to-pass-large-data-to-web-workers https://stackoverflow.com/questions/19152772/how-to-pass-lar...
- hsbauauvhabzb 5y ago

merb 5y ago

btw. this could also be interesting for spa applications that do not use node.js on the backend. I wonder when there will be code examples. I would really want to look more into spidermonkey+js in wasm and trying to get spa output.

vsroy 5y ago

I think the fact that you can save WASM memory / state will yield itself for very powerful applications in the future. I think there's a world where true time-travel debugging is possible because you execute your Python program inside of a WASM VM & with WASM, you can save the memory/local registers/etc. and do true backwards/forwards execution.

vlovich123 5y ago
Is there any reason to believe that this will be faster or more powerful than how reverse debugging works today? rr is already pretty fantastic and handles pretty complex cases surprisingly well with decent performance. I believe the way it works is that it only records memory changes of side-effect APIs (I.e. I/O, kernel, etc) & then just runs the program instruction backwards between those points. I’m not sure that snapshotting the entire RAM for an application will prove to be more efficient/powerful (copying large amounts of RAM is generally expensive). You might try to do crazy tricks like making the pages COW (while flushing them to disk) to reduce the actual cost of how many pages need to be copied. I think that’s still tough to compete with vs just recording the little bit of state around function calls that have side effects.
- miloignis 5y ago
  I've contemplated building a reverse debugger for wasm - rr is amazing, but frustrates me with touchy dependence on hardware features (sometimes doesn't work in a VM, doesn't support some CPUs, etc) and lack of ability to fork the timeline. I'd love to be able to backup, change a variable, and then proceed forwards - tree style undo and redo, as it were.
  - vlovich123 5y ago
    I haven’t tried but I’m pretty sure you can change variable values. Aside from it being Linux-only I haven’t encountered the CPU challenges. VM incompatibilities are a different story as I generally only ever run directly on metals when debugging. That being said, it looks like it does work (at least if you have sufficiently new software bits) so may be worth giving it another go: https://github.com/rr-debugger/rr/issues/2806 https://github.com/rr-debugger/rr/issues/2806

sandstrom 5y ago

I wonder if the new Wizer component can be used by other projects in the WebAssembly space, e.g. Wasmer? https://github.com/wasmerio/wasmer https://github.com/wasmerio/wasmer (Haven't fully grasped how they're different from wasmtime, but I think they've spend more effort on embedding the runtime into other languages)

ficklepickle 5y ago

I'm hoping this will be useful for improving react native performance on iOS. Due to restrictions on that platform the JS is currently interpreted and performance is terrible.

saagarjha 5y ago

Oh, interesting, it looks like Lin Clark is now at Fastly. I knew I recognized tho at art style…

skilesare 5y ago

If anyone out there is involved with this I am very interested and very motivated to figure out if I can get a JavaScript engine running in a DFINITY canister. I just need a compiled wasm and a candid file to try it out. I think. The wasm might need to be compiled in a particular way.