22 ms·

On my system (2015 MBP running Ubuntu 16.04) Rust's hello world compiles to a nearly 3.5 MB executable. Compiling the equivalent C program with clang results i

by cderwin 10y ago

On my system (2015 MBP running Ubuntu 16.04) Rust's hello world compiles to a nearly 3.5 MB executable. Compiling the equivalent C program with clang results in an executable under 9 KB. Rust may not have a GC, but its executables are certainly fat. Note: Rust executables can be trimmed down by stripping them (not done by default, even for release builds) and using libc malloc instead of jemalloc. But even then, C wins by a lot. Relevant blog post: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html#takeaway https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab...

Manishearth 10y ago
> But even then, C wins by a lot. C links dynamically to its libraries. Rust does not (by default). This overhead is a constant overhead so it rarely matters. When it does, you can strip it down further and get it to the same level as C. This is not evidence of a fat runtime, just a different default compilation strategy that prodces larger binary executables. jemalloc is (an optional) part of the runtime, but the rest isn't.
- cderwin 10y ago
  Sure. It's not a fair comparison. But dynamically linking rust's std isn't an option. If you are optimizing for executable size, c wins because dynamically linking libc is possible. This is even true controlling for glibc, since most rust code also dynamically links glibc too (including hello world). In fact, rust's hello world has quite a few more shared dependencies than the equivalent c anyway: it uses libdl, librt, libpthread, and libgcc_s as well.
  - Manishearth 10y ago
    Dynamically linking to rust std (with a specially compiled libstd dylib) is an option iirc, just that nobody does it. Lack of stable ABI makes it less useful, but if you really need to do it there's nothing stopping you. I suspect rust hello world using those libraries is due to a lack of LTO? Hello world doesn't need any of those.
mmstick 10y ago
Not a particularly fair comparison though, as that C binary is loading dynamic libraries that are already in memory. Case in point: that C program needs the C standard library, but by default that library (glibc) is dynamically loaded. Rust is not offering the Rust standard library as a dynamic library, hence the larger size. Not to mention, interfacing with C functions in the kernel. You'll get different results if you compile them with musl for truly static and fair binary size comparisons.
0xFFC 10y ago
I am no expert, but you should compile barebone executable for comparing executable size! not "hello world", because hello world does use shitload of library (for printing and loading and stuff), and those ones in C is compiled in dynamic, but in rust those compiled inot executable itself. if I remember correctly you should compile with --nostd flag and provide _start function for loader to load your executable! you can do same with rust too (But I think you should provide a special flag for compiler). You can find all of it on documentation.

by cderwin 10y ago

Manishearth 10y ago

> But even then, C wins by a lot. C links dynamically to its libraries. Rust does not (by default). This overhead is a constant overhead so it rarely matters. When it does, you can strip it down further and get it to the same level as C. This is not evidence of a fat runtime, just a different default compilation strategy that prodces larger binary executables. jemalloc is (an optional) part of the runtime, but the rest isn't.

cderwin 10y ago
Sure. It's not a fair comparison. But dynamically linking rust's std isn't an option. If you are optimizing for executable size, c wins because dynamically linking libc is possible. This is even true controlling for glibc, since most rust code also dynamically links glibc too (including hello world). In fact, rust's hello world has quite a few more shared dependencies than the equivalent c anyway: it uses libdl, librt, libpthread, and libgcc_s as well.
- Manishearth 10y ago
  Dynamically linking to rust std (with a specially compiled libstd dylib) is an option iirc, just that nobody does it. Lack of stable ABI makes it less useful, but if you really need to do it there's nothing stopping you. I suspect rust hello world using those libraries is due to a lack of LTO? Hello world doesn't need any of those.

mmstick 10y ago

Not a particularly fair comparison though, as that C binary is loading dynamic libraries that are already in memory. Case in point: that C program needs the C standard library, but by default that library (glibc) is dynamically loaded. Rust is not offering the Rust standard library as a dynamic library, hence the larger size. Not to mention, interfacing with C functions in the kernel. You'll get different results if you compile them with musl for truly static and fair binary size comparisons.

0xFFC 10y ago

I am no expert, but you should compile barebone executable for comparing executable size! not "hello world", because hello world does use shitload of library (for printing and loading and stuff), and those ones in C is compiled in dynamic, but in rust those compiled inot executable itself. if I remember correctly you should compile with --nostd flag and provide _start function for loader to load your executable! you can do same with rust too (But I think you should provide a special flag for compiler). You can find all of it on documentation.