Bloated `so` binaries

[gektorbr]

I'm curios to understand the reason why so modules produced by lucetc are so large. For instance let's compile the code below with Lucet's toolchain and gcc. The binary produced by gcc is pretty compact. It's just 15KB when compiled with -Oz option. The so module from Lucet is almost 400KB. I've tried different clang and lucetc options, also applied strip. It doesn't matter. so remains 350KB+.

Is there some technological limitation under the hood? Can the size of the binaries be reduced?

#include <iostream>
#include <list>
#include <vector>

using namespace std;

int main() {

    list<string> ls;
    ls.push_back("one");
    ls.push_back("two");
    ls.push_back("three");

    for (auto v : ls) {
        cout << v << "\n";
    }

    vector<string> vs;
    vs.push_back("one");
    vs.push_back("two");
    vs.push_back("three");

    for (auto v : vs) {
        cout << v << "\n";
    }

    return 0;
}

[pchickey]

Its unclear to me whether this is a Lucet issue, or whether the Wasm produced by clang for this c++ program is just really big. When I compile it with wasi-sdk 8, /opt/wasi-sdk/bin/clang++ test.cpp -fno-exceptions -o test.wasm the resulting binary is 673570 bytes. There are ~1700 funcs and at least 17k of data segments.

[sunfishcode]

The 15K native case with gcc is presumably using dynamic linking, so it doesn't include the C++ standard library. You can see the effect of static linking by compiling with -static in your native build, which can increase the size of the executable considerably.

[gektorbr]

You are right! Size of so should be compared to a binary compiled statically

[iximeow]

When comparing to a statically compiled application, do you see more comparable sizes? Our bookkeeping for Lucet implementation reasons should only be on the order of 64 bytes per function, so I certainly hope they would be much closer.