3 ms·
This is cool. I'm surprised that compiling a partial Zig backend to WASM and then compressing that ends up meaningfully smaller than compiling to C and compres
by kalkin 4y ago
This is cool.
I'm surprised that compiling a partial Zig backend to WASM and then compressing that ends up meaningfully smaller than compiling to C and compressing the C, when you include also the C partial WASM implementation and zstd decoder. This sounds kind of like a general strategy for compressing C code which I would not have expected to work well, but cool that it does!
If AndyKelley ends up reading this - did you end up doing a direct comparison of "zig1.c.zstd + zstd.c" size vs the "zig1.wasm.zstd + zstd.c + wasm.c.zstd" set that you ended up with? If so, how did it turn out?
- AndyKelley 4y agoI ran the command locally just now: zig1-x86_64-linux.c: 86 MiB zig1-x86_64-linux.c.zstd: 3.5 MiB
- kristoff_it 4y agoI think it boils down to how bloated is the C code generated by the C backend, which to some degree has to be, since it's generated programmatically. My undestanding is what ends up happening is that the wasm step acts as a form of semantic compression that brings its own benefits over zstd (and which can still be combined with zstd by compressing the wasm file).
- nektro 4y agothis is likely due to LLVM being involved in the WASM generation and it being able to perform all of its optimization steps before outputting code. whereas Zig's C backend has not yet gained the ability to perform all the same optimizations.