6 ms·

And some rough numbers, rustc-1.30.1 vs rustc-1.32.0-2018-11-21, building a hello world with --release... Mac OS: - 1.30.1 before strip: 573K, after strip: 38

by vesak 8y ago

And some rough numbers, rustc-1.30.1 vs rustc-1.32.0-2018-11-21, building a hello world with --release... Mac OS: - 1.30.1 before strip: 573K, after strip: 380K - 1.32.0 before strip: 267K, after strip: 178K Ubuntu 18.04 LTS: - 1.30.1 before strip: 3.9M, after strip: 407K - 1.32.0 before strip: 2.3M, after strip: 191K

kungtotte 8y ago
I'm on Void Linux right now running Nim 0.19 compiling the following code: when isMainModule: echo "Hello World" nim c hello.nim: Before strip: 113k After strip: 92k nim c -d:release hello.nim: Before strip: 79k After strip: 63k nim c -d:release --opt:size hello.nim: Before strip: 46k After strip: 30k Kind of a toy example but it illustrates my point. An unstripped version of the Nim program with full debug symbols is still 78k smaller than the stripped, release version of the Rust equivalent. But it's great that they're trying to work on this problem.
- nimmer 8y ago
  The difference gets bigger on large binaries.
- vesak 8y ago
  >But it's great that they're trying to work on this problem. I don't know how the Rust team thinks, but I believe that minimizing binary sizes is not a very big priority for them. The cost of a gigabyte these days is, ~0.01$ (or less) for local hard drives, $0.4 for NVME and about $0.1 for AWS EBS... Technically of course it's cool how small Nim binaries are, and it does make certain things feasible which with larger binary sizes might be difficult.
  - steveklabnik 8y ago
    We think it's important to be able to control it if you need to, and have done work to make that possible. But we don't worry about the default too much, as you say, we've got a lot of things to worry about, and it's not near the top of the list. That said, the smallest executable produced is 145 bytes: https://github.com/tormol/tiny-rust-executable https://github.com/tormol/tiny-rust-executable

by vesak 8y ago

kungtotte 8y ago

I'm on Void Linux right now running Nim 0.19 compiling the following code: when isMainModule: echo "Hello World" nim c hello.nim: Before strip: 113k After strip: 92k nim c -d:release hello.nim: Before strip: 79k After strip: 63k nim c -d:release --opt:size hello.nim: Before strip: 46k After strip: 30k Kind of a toy example but it illustrates my point. An unstripped version of the Nim program with full debug symbols is still 78k smaller than the stripped, release version of the Rust equivalent. But it's great that they're trying to work on this problem.

nimmer 8y ago
The difference gets bigger on large binaries.
vesak 8y ago
>But it's great that they're trying to work on this problem. I don't know how the Rust team thinks, but I believe that minimizing binary sizes is not a very big priority for them. The cost of a gigabyte these days is, ~0.01$ (or less) for local hard drives, $0.4 for NVME and about $0.1 for AWS EBS... Technically of course it's cool how small Nim binaries are, and it does make certain things feasible which with larger binary sizes might be difficult.
- steveklabnik 8y ago
  We think it's important to be able to control it if you need to, and have done work to make that possible. But we don't worry about the default too much, as you say, we've got a lot of things to worry about, and it's not near the top of the list. That said, the smallest executable produced is 145 bytes: https://github.com/tormol/tiny-rust-executable https://github.com/tormol/tiny-rust-executable