-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question about WASM binary size using tot (musl 1.2.2) #15483
Comments
That is a size increase that we would like to avoid if possible. I wonder if you can help track down the differences? Perhaps you could attach the different builds (with My hope is that there is some major chunk of libc that was not includes before and that is now being included and that wecan find a way to remove that dependency and reduce the binary size. Perhaps something like string formatting? |
tot vs old (2.0.34) using bloaty:
If i read this right, most of the size increase happens in the data section. Not sure how to further see what's going on there. |
Nice! Thanks for investigating. It does look like the data section is the significant change here. I imagine its related to the exp2 and log functions, perhaps they have a lot of associated table data? We need to figure out a way to analyze the differences in the data section. I think there are some flags that will allow the final binary to contain a data section which is split in to individual named chunks, but I will have to get back to you on that. In the mean time can have a look at where those "NEW" symbols are coming from by running passing |
Building with |
Sadly it looks like bloaty doesn't break down the data segments, but you can use |
If that doesn't work out, building small programs to test individual functions might help. I tried this now on #include <math.h>
int main(int argc, char **argv) {
return exp2(double(argc) / 3.1415921828);
} The new version is actually 40% smaller. Reading musl's exp2.c it looks like it was completely rewritten. |
Thank you for all that great input. I used Removing all entries that are on both sides, I am left with this result:
So in the old build there was I have no idea what |
I can also see @kripken 's minimal example being around 40% smaller. I think it is because previously the I came up with another slightly more complex example which shows the increase: #include <math.h>
int main(int argc, char **argv) {
double num = double(argc);
return exp2(num / 3.1415921828) + exp(num) - exp(-num) + log((1 + num) / (1 - num)) + log2(num);
} With this I get around 11k (tot), and only 6.1k (old musl). It shows the same differences in the data section as with my obersation above. |
I really have no idea what to do about this. I think within musl it boils down to these commits? bminor/musl@2a3210c bminor/musl@e16f7b3 Should provide a speedup for those log functions, does that generally translate to WASM as well? |
Thanks @haberbyte! I looks like you tracked it down. We will see what we can do about reverting that change or pehaps making it |
I noticed that my observations can be simplified down to the It is because exp/exp2 actually have size improvements, but the new So maybe just "reverting" to system/libc/musl/src/math/log.c and system/libc/musl/src/math/log2.c ? |
Restore the older versions of these files and used them in place of the new ones when optimizing for size. These regressions were intended and deemed acceptable in upsteeam musl: emscripten-core/musl@e4dd653 emscripten-core/musl@2a3210c emscripten-core/musl@236cd05 Fixes: #15483
Restore the older versions of these files and used them in place of the new ones when optimizing for size. These regressions were intended and deemed acceptable in upsteeam musl: emscripten-core/musl@e4dd653 emscripten-core/musl@2a3210c emscripten-core/musl@236cd05 Fixes: #15483
Restore the older versions of these files and used them in place of the new ones when optimizing for size. These regressions were intended and deemed acceptable in upsteeam musl: emscripten-core/musl@e4dd653 emscripten-core/musl@2a3210c emscripten-core/musl@236cd05 Fixes: #15483
Restore the older versions of these files and used them in place of the new ones when optimizing for size. These regressions were intended and deemed acceptable in upsteeam musl: emscripten-core/musl@e4dd653 emscripten-core/musl@2a3210c emscripten-core/musl@236cd05 Fixes: #15483
Restore the older versions of these files and used them in place of the new ones when optimizing for size. These regressions were intended and deemed acceptable in upsteeam musl: emscripten-core/musl@e4dd653 emscripten-core/musl@2a3210c emscripten-core/musl@236cd05 Fixes: #15483
Restore the older versions of these files and used them in place of the new ones when optimizing for size. These regressions were intended and deemed acceptable in upsteeam musl: emscripten-core/musl@e4dd653 emscripten-core/musl@2a3210c emscripten-core/musl@236cd05 Fixes: #15483
…de (#15544) Restore the older versions of these files and used them in place of the new ones when optimizing for size. These regressions were intended and deemed acceptable in upsteeam musl: emscripten-core/musl@e4dd653 emscripten-core/musl@2a3210c emscripten-core/musl@236cd05 Fixes: #15483
…de (emscripten-core#15544) Restore the older versions of these files and used them in place of the new ones when optimizing for size. These regressions were intended and deemed acceptable in upsteeam musl: emscripten-core/musl@e4dd653 emscripten-core/musl@2a3210c emscripten-core/musl@236cd05 Fixes: emscripten-core#15483
The update to musl 1.2.2 did not cause any issues so far, just leaving this as a general observation, so 👍
So this issue could probably be closed if the following is expected.
I noticed my wasm binary size increases a bit with the latest musl changes.
On
2.0.34
builds i get:-Oz: 148K
-O3: 220k
On
tot
builds i get:-Oz: 153K
-O3: 230k
Given that this is just around 3% increase, is that within reason and expected?
It is still a bit disappointing and i wonder what parts are causing this.
The text was updated successfully, but these errors were encountered: