Huge code bloat with wasi-sdk-23

[sparker-arm]

Hi,

I've just updated my benchmark binaries to compile with 23, instead of 22. I'm seeing code size changes that I don't understand, maybe changes in how the libraries are built? Has anyone noticed similar changes? Below is my git pull log which caught my attention!

cheers,
Sam

 benchmarks/adobe/wasm/functionobjects.wasm         | Bin 508408 -> 646733 bytes
 benchmarks/adobe/wasm/loop_unroll.wasm             | Bin 477734 -> 631955 bytes
 benchmarks/adobe/wasm/stepanov_vector.wasm         | Bin 122282 -> 274559 bytes
 benchmarks/aha/wasm/aha.wasm                       | Bin 33029 -> 152764 bytes
 benchmarks/alac/wasm/encode.wasm                   | Bin 163918 -> 374160 bytes
 benchmarks/bullet/wasm/1000-convex.wasm            | Bin 889848 -> 1080895 bytes
 benchmarks/bullet/wasm/1000-stack.wasm             | Bin 889847 -> 1080894 bytes
 benchmarks/bullet/wasm/136-ragdolls.wasm           | Bin 889849 -> 1080896 bytes
 benchmarks/bullet/wasm/3000-fall.wasm              | Bin 889846 -> 1080893 bytes
 benchmarks/bullet/wasm/convex-trimesh.wasm         | Bin 889851 -> 1080898 bytes
 benchmarks/bullet/wasm/prim-trimesh.wasm           | Bin 889849 -> 1080896 bytes
 benchmarks/bullet/wasm/raytests.wasm               | Bin 889845 -> 1080892 bytes
 benchmarks/jetstream2/wasm/float-mm.wasm           | Bin 21266 -> 102339 bytes
 benchmarks/jetstream2/wasm/gcc-loops.wasm          | Bin 2415704 -> 2777604 bytes
 benchmarks/jetstream2/wasm/hashset.wasm            | Bin 2716050 -> 3078733 bytes
 benchmarks/jetstream2/wasm/quicksort.wasm          | Bin 20233 -> 104079 bytes
 benchmarks/jetstream2/wasm/richards.wasm           | Bin 29787 -> 150670 bytes
 benchmarks/llama2/wasm/run.wasm                    | Bin 91974 -> 364223 bytes
 benchmarks/lzma/wasm/lzma.wasm                     | Bin 79858 -> 202837 bytes  
 benchmarks/meshoptimizer/wasm/codecbench.wasm      | Bin 93145 -> 219666 bytes   
 benchmarks/minisat/wasm/minisat.wasm               | Bin 120254 -> 361591 bytes
 benchmarks/oggenc/wasm/oggenc.wasm                 | Bin 1198354 -> 1491969 bytes
 benchmarks/olden/wasm/bisort.wasm                  | Bin 30221 -> 150810 bytes
 benchmarks/olden/wasm/em3d.wasm                    | Bin 32955 -> 157059 bytes
 benchmarks/olden/wasm/health.wasm                  | Bin 31865 -> 154573 bytes
 benchmarks/olden/wasm/mst.wasm                     | Bin 31427 -> 152016 bytes   
 benchmarks/olden/wasm/perimeter.wasm               | Bin 30454 -> 148273 bytes
 benchmarks/olden/wasm/power.wasm                   | Bin 32960 -> 152747 bytes   
 benchmarks/olden/wasm/treeadd.wasm                 | Bin 29255 -> 149844 bytes  
 benchmarks/olden/wasm/tsp.wasm                     | Bin 36749 -> 162879 bytes 
 benchmarks/olden/wasm/voronoi.wasm                 | Bin 46459 -> 175376 bytes 
 benchmarks/pairlocalalign/wasm/pairlocalalign.wasm | Bin 297406 -> 579510 bytes
 benchmarks/peanut-gb/wasm/peanut-gb.wasm           | Bin 146626 -> 245030 bytes
 benchmarks/pocket-nn/wasm/pocketnn.wasm            | Bin 2435239 -> 2797863 bytes
 benchmarks/polybench/wasm/2mm.wasm                 | Bin 33802 -> 154904 bytes   
 benchmarks/polybench/wasm/3mm.wasm                 | Bin 34214 -> 155316 bytes 
 benchmarks/polybench/wasm/adi.wasm                 | Bin 33920 -> 155022 bytes 
 benchmarks/polybench/wasm/atax.wasm                | Bin 33041 -> 154143 bytes   
 benchmarks/polybench/wasm/bicg.wasm                | Bin 32687 -> 153789 bytes
 benchmarks/polybench/wasm/cholesky.wasm            | Bin 33011 -> 154113 bytes
 benchmarks/polybench/wasm/correlation.wasm         | Bin 34013 -> 155115 bytes
 benchmarks/polybench/wasm/covariance.wasm          | Bin 33598 -> 154700 bytes
 benchmarks/polybench/wasm/doitgen.wasm             | Bin 33348 -> 154450 bytes
 benchmarks/polybench/wasm/durbin.wasm              | Bin 33498 -> 154600 bytes
 benchmarks/polybench/wasm/dynprog.wasm             | Bin 33953 -> 155055 bytes
 benchmarks/polybench/wasm/fdtd-2d.wasm             | Bin 34449 -> 155551 bytes
 benchmarks/polybench/wasm/floyd-warshall.wasm      | Bin 32575 -> 153677 bytes
 benchmarks/polybench/wasm/gemm.wasm                | Bin 33111 -> 154213 bytes
 benchmarks/polybench/wasm/gemver.wasm              | Bin 34009 -> 155111 bytes
 benchmarks/polybench/wasm/gesummv.wasm             | Bin 32724 -> 153826 bytes
 benchmarks/polybench/wasm/gramschmidt.wasm         | Bin 33973 -> 155075 bytes
 benchmarks/polybench/wasm/jacobi-1d-imper.wasm     | Bin 32894 -> 153996 bytes
 benchmarks/polybench/wasm/jacobi-2d-imper.wasm     | Bin 33088 -> 154190 bytes
 benchmarks/polybench/wasm/lu.wasm                  | Bin 32943 -> 154045 bytes
 benchmarks/polybench/wasm/ludcmp.wasm              | Bin 33955 -> 155057 bytes
 benchmarks/polybench/wasm/mvt.wasm                 | Bin 33158 -> 154260 bytes
 benchmarks/polybench/wasm/reg_detect.wasm          | Bin 37088 -> 158190 bytes
 benchmarks/polybench/wasm/seidel-2d.wasm           | Bin 32531 -> 153633 bytes
 benchmarks/polybench/wasm/symm.wasm                | Bin 33087 -> 154189 bytes
 benchmarks/polybench/wasm/syr2k.wasm               | Bin 33416 -> 154518 bytes
 benchmarks/polybench/wasm/syrk.wasm                | Bin 33047 -> 154149 bytes
 benchmarks/polybench/wasm/trisolv.wasm             | Bin 32509 -> 153611 bytes
 benchmarks/polybench/wasm/trmm.wasm                | Bin 32845 -> 153947 bytes
 benchmarks/quickjs/wasm/quickjs.wasm               | Bin 928646 -> 1272433 bytes
 benchmarks/raytracing/wasm/ray.wasm                | Bin 2399738 -> 2762424 bytes
 benchmarks/raytracing/wasm/smallpt.wasm            | Bin 96937 -> 317912 bytes
 benchmarks/raytracing/wasm/sphereflake.wasm        | Bin 2399958 -> 2762644 bytes
 benchmarks/shootout/wasm/binarytrees.wasm          | Bin 32025 -> 154471 bytes
 benchmarks/shootout/wasm/fannkuchredux.wasm        | Bin 30707 -> 150624 bytes
 benchmarks/shootout/wasm/fasta.wasm                | Bin 49609 -> 203531 bytes
 benchmarks/shootout/wasm/meteor.wasm               | Bin 2403848 -> 2766607 bytes
 benchmarks/shootout/wasm/nbody.wasm                | Bin 32955 -> 150771 bytes
 benchmarks/shootout/wasm/spectralnorm.wasm         | Bin 2396611 -> 2760153 bytes
 benchmarks/spec2017/wasm/508.namd_r.wasm           | Bin 926211 -> 1207218 bytes
 benchmarks/spec2017/wasm/525.x264_r.wasm           | Bin 668771 -> 984164 bytes
 benchmarks/spec2017/wasm/531.deepsjeng_r.wasm      | Bin 141565 -> 392130 bytes
 benchmarks/spec2017/wasm/544.nab_r.wasm            | Bin 188731 -> 490742 bytes
 benchmarks/spiff/wasm/spiff.wasm                   | Bin 69690 -> 287388 bytes
 benchmarks/sqlite3/wasm/sqlite3.wasm               | Bin 1395264 -> 1704213 bytes
 benchmarks/tramp3d-v4/wasm/tramp3d-v4.wasm         | Bin 4768150 -> 5157573 bytes
 benchmarks/tsvc/wasm/tsvc.wasm                     | Bin 231640 -> 364655 bytes
 benchmarks/wasm3/wasm/wasm3.wasm                   | Bin 179305 -> 434474 bytes
 benchmarks/zlib-bench/wasm/zlib-bench.wasm         | Bin 2856892 -> 3218373 bytes

[yamt]

maybe changes in how the libraries are built?

i think the recent migration to cmake effectively added -g.
i guess you can strip your binaries.

[sparker-arm]

i think the recent migration to cmake effectively added -g.

Ah, that would make sense. Was it an intended change?

[sparker-arm]

@alexcrichton From your commit, I assume that the libraries should not have been built with debug?

[alexcrichton]

This was an intentional change in #422 pre-cmake. The assumption was that this is useful information that cannot otherwise be generated and it's relatively easy to strip through various CLI tools or the -Wl,--strip-debug compiler flag.

[sparker-arm]

Okay... It was somewhat surprising though, I presume this is a change to make life more easier fo wasi-sdk devs? When I'm building wasi-sdk myself, is there a rune/build target I can use to revert to the old behaviour?

[alexcrichton]

While I'm not sure what a rune is when you're building the sysroot from this repository you can configure what's build with CMAKE_BUILD_TYPE to change it from the default. I believe Release for example will not have any debuginfo.

[sbc100]

Whatever wask-sdk does, I would recommend explicitly stripping your release binaries using strip/llvm-strip, on all platforms.

[sparker-arm]

you can configure what's build with CMAKE_BUILD_TYPE to change it from the default.

Thanks! That has worked, though I'm still unsure why this the default for a distributed release build.

I would recommend explicitly stripping your release binaries using strip/llvm-strip, on all platforms.

Noted. Is there a document somewhere that lays out the recommended developer flow? I'm used to invoking a compiler and that being it :)

[rajsite]

Whatever wask-sdk does, I would recommend explicitly stripping your release binaries using strip/llvm-strip, on all platforms.

Sorry, I'm certainly doing something silly and would appreciate some pointers.

On sdk 24, with hw.c file:

int printf(const char *, ...); int main(){printf("hello world!\n");}

Compiled with:

.\wasi-sdk-24.0-x86_64-windows\bin\clang.exe --sysroot=.\wasi-sdk-24.0-x86_64-windows\share\wasi-sysroot --target=wasm32-wasip2 -O3 hw.c -o hw.wasm

I get a WASM component file that if I plop into http://wa2.dev shows imports for lots of things I don't use (tcp, udp, etc) and tons of wat. Sounds like strip/llvm-strip is expected to help with that?

If I try to run the cli tool it doesn't seem to handle the wasm (which I'm not super clear on what tooling I should expect handles wasm modules / components in llvm):

>wasi-sdk-24.0-x86_64-windows\bin\llvm-strip.exe hw.wasm                              
wasi-sdk-24.0-x86_64-windows\bin\llvm-strip.exe: error: 'hw.wasm': invalid version number: 65549

In this trivial setup know how I can get strip to work / have a more reasonable component output?

Attached are the hw.c and hw.wasm component output: hw.zip

[alexcrichton]

@rajsite looks like you're building a component with the wasm32-wasip2 target instead of a core wasm module with the wasm32-wasip1 target. The wasi-libc implementation of components imports tcp/udp/etc to implement the write libc function due to how the implementation works.

The llvm-strip executable doesn't know how to work with components at this time which is why you're getting this error. You'll want to use wasm-tools strip instead for now.

Otherwise the "strip" functionality is primarily centered around removing custom sections, so the strip tool will not be suitable for what you're trying to achieve which is to remove imports. If you're interested in that I'd recommend opening a separate issue as I believe it's unrelated to this one about debuginfo.

[rajsite]

Gotcha, I see the difference. I'll create a separate issue to discuss the import behavior. Thanks for clarifying!

In the context of this issue, is there an expected workflow for stripping debug info when using wasm32-wasip2 (I'm not completely certain how to identify if it's an issue as well for this target)? Any spot I can track the progress / see the expected states of the different targets?

[alexcrichton]

The comment above of using -Wl,--strip-debug should work for wasm32-wasip2 as a compile-time option for stripping debug information. After compilation has completed the only tool to strip currently is wasm-tools strip for components.

[rajsite]

Appreciate it! On the clang cli

clang.exe --sysroot=.\wasi-sdk-24.0-x86_64-windows\share\wasi-sysroot --target=wasm32-wasip2 -Wl,--strip-debug -O3 hw.c -o hw2.wasm

Stripping out the debug sections reduced the size quite a bit:

-rw-rw-rw-    1 mraj 0 210K 2024-08-14 13:32 hw.wasm
-rw-rw-rw-    1 mraj 0  42K 2024-08-14 13:32 hw2.wasm

I'll keep poking at handling the unused imports and create a separate issue for that.

[rajsite]

Noted. Is there a document somewhere that lays out the recommended developer flow? I'm used to invoking a compiler and that being it :)

I've been trying to find docs like this and the closet I have seen is this PR to the component-model docs repo: bytecodealliance/component-docs#66

But it doesn't cover the expected workflow of stripping release release binaries either.