Oxidizing Source Maps with Rust and WebAssembly
hacks.mozilla.org
Oxidizing Source Maps with Rust and WebAssembly
1–10 of 32 posts
Re: Oxidizing Source Maps with Rust and WebAssembly
#2> Tom Tromey and I have replaced the most performance-sensitive portions of the source-map JavaScript Library’s source map parser with Rust code that is compiled to WebAssembly. The WebAssembly is up to 5.89 times faster than the JavaScript implementation on realistic benchmarks operating on real world source maps.
Wow. Some people have been wondering if Rust has a "killer app", but this could be it. Right now WebAssembly only supports non-GC languages (so C, C++, and Rust), and of those three Rust is the easiest to get started with. It looks really appealing.
Re: Oxidizing Source Maps with Rust and WebAssembly
#3> Tom Tromey and I have replaced the most performance-sensitive portions of the source-map JavaScript Library’s source map parser with Rust code that is compiled to WebAssembly. The WebAssembly is up to 5.89 times faster than the JavaScript implementation on realistic benchmarks operating on real world source maps. Wow. Some people have been wondering if Rust has a "killer app", but this could be it. Right now WebAss…
I personally am a huge advocate of this vision.
This stuff is a bit hard to get into at the moment, as it's early days, but as things coalesce, we're also working on making everything well documented and super-smooth to use. It's already reasonably easy, but we want it to be trivial.
Re: Oxidizing Source Maps with Rust and WebAssembly
#4> Tom Tromey and I have replaced the most performance-sensitive portions of the source-map JavaScript Library’s source map parser with Rust code that is compiled to WebAssembly. The WebAssembly is up to 5.89 times faster than the JavaScript implementation on realistic benchmarks operating on real world source maps. Wow. Some people have been wondering if Rust has a "killer app", but this could be it. Right now WebAss…
Yup, allocation and performance are tightly tied for a variety of reasons. Languages like Rust that have a nuanced control over allocation will exceed in spaces like this.
Re: Oxidizing Source Maps with Rust and WebAssembly
#5VLQ decoding is sort of subtle, and the one shown in the article under "Base 64 Variable Length Quantities" looks broken.
1. `shift` can grow large, and an overlong left shift will panic in Rust. I expect an input like "gggggggC" to crash.
2. `accum >>= 1` is wrong because it rounds down. It needs to be a round-towards-zero: `accum /= 2`.
3. `accum` is a 32 bit int which is too small. It needs to be larger so it can represent -2^31 in sign-magnitude form.
Re: Oxidizing Source Maps with Rust and WebAssembly
#6VLQ decoding is sort of subtle, and the one shown in the article under "Base 64 Variable Length Quantities" looks broken. 1. `shift` can grow large, and an overlong left shift will panic in Rust. I expect an input like "gggggggC" to crash. 2. `accum >>= 1` is wrong because it rounds down. It needs to be a round-towards-zero: `accum /= 2`. 3. `accum` is a 32 bit int which is too small. It needs to be larger so it can…
Thanks for the report!
We've already fixed some of these issues[0] but I didn't update the code snippets in the article -- woops!
[0] https://github.com/tromey/vlq/commit/3b41a2b6c778ce476eaaa28...
Re: Oxidizing Source Maps with Rust and WebAssembly
#7Wow, I had assumed a lot more of the Rust runtime/stdlib would need to come along with anything, but the wasm-unknown-unknown target and aggressive culling of unused code looks to make this really competitive. That's awesome, and I'm really happy to have my predictions and assumptions proven wrong. :)
Edit: Some of the numbers:
Original JS: just under 30,000 bytes.
Closure compiler minified JS: 8,365 bytes.
New combined JS and WASM: 20,996 bytes
Roughly half of the WASM output is JS and half of which is WASM, since not all components in the original JS were replaced, just a specific subset. There is some duplication of functions that both the remaining JS still uses and the new WASM code does as well. Rust diagnostic and error messages appear to still be present inthe data section although unusable, so could be cleared out with better tooling.
Re: Oxidizing Source Maps with Rust and WebAssembly
#8Wow, I had assumed a lot more of the Rust runtime/stdlib would need to come along with anything, but the wasm-unknown-unknown target and aggressive culling of unused code looks to make this really competitive. That's awesome, and I'm really happy to have my predictions and assumptions proven wrong. :) Edit: Some of the numbers: Original JS: just under 30,000 bytes. Closure compiler minified JS: 8,365 bytes. New combi…
The smallest file we've gotten so far is 116 bytes. I went over it here https://www.reddit.com/r/programming/comments/7fn87w/rust_wa...
Re: Oxidizing Source Maps with Rust and WebAssembly
#9> Tom Tromey and I have replaced the most performance-sensitive portions of the source-map JavaScript Library’s source map parser with Rust code that is compiled to WebAssembly. The WebAssembly is up to 5.89 times faster than the JavaScript implementation on realistic benchmarks operating on real world source maps. Wow. Some people have been wondering if Rust has a "killer app", but this could be it. Right now WebAss…
Why do you say Rust is easier to start with than C or C++?
[Disclaimer : i'm old enough to dream in K&R C and later ANSI C, and then C++, but am more than enthused about Rust, so a genuine question]
Re: Oxidizing Source Maps with Rust and WebAssembly
#10> Tom Tromey and I have replaced the most performance-sensitive portions of the source-map JavaScript Library’s source map parser with Rust code that is compiled to WebAssembly. The WebAssembly is up to 5.89 times faster than the JavaScript implementation on realistic benchmarks operating on real world source maps. Wow. Some people have been wondering if Rust has a "killer app", but this could be it. Right now WebAss…
Why do you say Rust is easier to start with than C or C++? [Disclaimer : i'm old enough to dream in K&R C and later ANSI C, and then C++, but am more than enthused about Rust, so a genuine question]
I would guess that a language in where the compiler holds your hand so you don't shoot yourself in the foot is probably by definition a bit easier than one that hides traps for you behind corner every now and then :)