Mashi - A compressor for JS/WASM 64k intros
category: code [glöplog]
I am not familar with wasm/js, but considering switching because of this wonderful tool, so I am curious and honestly asking:
Why the focus on wasm over JS?
What are we compiling to wasm that is better than JS? Not C/C++ via emscripten, as you pointed out sagacity, that was my conclusion as well.
It's been on my mind. What are the compressed size and performance characteristics of javascript versus other languages you can compile to wasm? Is it really beatable?
Are you guys using some magical language? Or is the performance of JIT js just worse than I think?
Why the focus on wasm over JS?
What are we compiling to wasm that is better than JS? Not C/C++ via emscripten, as you pointed out sagacity, that was my conclusion as well.
It's been on my mind. What are the compressed size and performance characteristics of javascript versus other languages you can compile to wasm? Is it really beatable?
Are you guys using some magical language? Or is the performance of JIT js just worse than I think?
Just want to remind everyone that this exists, and confirm that it works as advertised.
We used it in raltron: https://www.pouet.net/prod.php?which=106875
Javascript is now an awesome platform for 64kb intros. I would encourage you all to give it a go.
We used it in raltron: https://www.pouet.net/prod.php?which=106875
Javascript is now an awesome platform for 64kb intros. I would encourage you all to give it a go.
It's probably also a decent combination with wgslender if you're doing WebGPU stuff.
Hi Sagacity, I was playing with Mashi today, and I have a question because I think I'm not using it the way it's meant to be used.
So I have this experiment with a 1.7 kilobyte WASM that implements a mandelbrot animation in GLSL, a tiny JS to create the canvas, setup WebGL2 and interface with the WASM, and a mostly empty HTML.
I'm building the WASM in C++ (Visual Studio 2022) with Emscripten (6.0.10), but I skip all the standard libs and all the crap it comes with, so my uncompressed WASM is 1.7 kilobytes for now (can probably do better, not the point). The JS is also not experimental and not optimized at all, but it's 3kb when minified (but should be smaller eventually, also not the point for now). The html is mostly blank.
So I have this when I take this current combo of JS(3kb)+WASM(1.6kb)+HTML(0kb) and just ZIP it, I get a 3 kilobyte ZIP.
But when I mashi-pack-it, it get a 6 kilobytes output.html, which makes me thing that I might not be using Mashi correctly, or I am producing my intro in a way that Mashi is not meant to work with? Is there anything special I need to do to the WASM for Mashi to detect the data segments vs the code segments so it can do its magic?
I found you in Linked-in, but if there's a better way to connect let me know.
So I have this experiment with a 1.7 kilobyte WASM that implements a mandelbrot animation in GLSL, a tiny JS to create the canvas, setup WebGL2 and interface with the WASM, and a mostly empty HTML.
I'm building the WASM in C++ (Visual Studio 2022) with Emscripten (6.0.10), but I skip all the standard libs and all the crap it comes with, so my uncompressed WASM is 1.7 kilobytes for now (can probably do better, not the point). The JS is also not experimental and not optimized at all, but it's 3kb when minified (but should be smaller eventually, also not the point for now). The html is mostly blank.
So I have this when I take this current combo of JS(3kb)+WASM(1.6kb)+HTML(0kb) and just ZIP it, I get a 3 kilobyte ZIP.
But when I mashi-pack-it, it get a 6 kilobytes output.html, which makes me thing that I might not be using Mashi correctly, or I am producing my intro in a way that Mashi is not meant to work with? Is there anything special I need to do to the WASM for Mashi to detect the data segments vs the code segments so it can do its magic?
I found you in Linked-in, but if there's a better way to connect let me know.
I suppose the answer is that the compressor is really designed for 64k, not for 4k, and is relatively large compared to the 4k sizes I was targeting? I should have realized that before posting.
Mashi's readme says:
-- source
Quote:
The decompression stub is written in pure WASM and takes about 2.5k when using the WASM context model (--wasm), or about 2k when it isn't needed (JS-only packing and --bin).
-- source
iq: That's right. It's really intended for 64k intros because the decompression stub is pretty large, but it gets (much?) better compression than regular js droppers that are based on compression algorithms built into the browser. The tradeoff is that Mashi's decompressor is also bigger.
How big is the overhead of Mashi excluding the decompressor? I.e. what would be the unavoidable base overhead if one were to design a smaller decompressor targeting e.g. 4k using the same methods as Mashi otherwise?
You mean the HTML bootstrap that loads the binary data, deflate them and call the unpacker ? ~247 bytes
https://github.com/datatrash/mashi/blob/26b8844c913c01062bc1426b3ad4d437cf925be2/src/cli/header.html
https://github.com/datatrash/mashi/blob/26b8844c913c01062bc1426b3ad4d437cf925be2/src/cli/header.html
and the stub instantiating and calling the wasm unpacker is 416b minified. But it's also packed in the initial deflate binary data.
https://github.com/datatrash/mashi/blob/26b8844c913c01062bc1426b3ad4d437cf925be2/generated/depacker.js.min
https://github.com/datatrash/mashi/blob/26b8844c913c01062bc1426b3ad4d437cf925be2/generated/depacker.js.min