3 ms·

Tiny Binaries (2021)

peter_d_sherman 3y ago
Related: https://pablotron.org/2022/03/02/tiny-binaries-redux/ https://pablotron.org/2022/03/02/tiny-binaries-redux/
CyberDildonics 3y ago
Hello world in rust starts at 2.5 MB ? That's disgusting. With C++ and FLTK you can draw a GUI window that says hello world with your static binaries starting at 100KB
- joseluis 3y ago
  That must be without stripping. Also there are ways to reduce binary size. See e.g. [min-sized-rust](https://github.com/johnthagen/min-sized-rust https://github.com/johnthagen/min-sized-rust). I've gotten stripped binaries of small cli utils less than 400KiB without doing anything special, less than 150 KiB by customizing profile settings and compressing with upx, and less than 30 KiB by replacing the std with the libc as the link shows. Haven't tried with fltk though...
  - cinntaile 3y ago
    UPX compressed files used to get flagged by antivirus software, is that not the case anymore?
    - Brian_K_White 3y ago
      I think practical/application issues are out of scope here as this is more like an academic study of a single dimension. upx being acceptable or not is no different than how none of the best performing examples here would be acceotable in most situations either, not just the upx ones, just for other reasins. No company making a random app that didn't have a critical need for this metric would tolerate you writing it in assembly or even c with muscl etc instead of something everyone else can maintain.
      - CyberDildonics 3y ago
        uTorrent took over an entire market segment by being super fast and small. Some people value fast and small software when it happens, there is no reason to accept ridiculous bloat like rust needing multiple megabytes to print a string to stdout. This is just a reminder of how much nonsense languages like rust are packing into their binaries without regard for the people using them.
        Brian_K_White 3y ago
        No argument. The point was only that far fewer people can work on assembly, and far fewer want to live within the limits imposed by things like muscl. They all expect to code in high level magic environments just like their huge ides with language servers, and their bosses expect a level of productivity that requires that too. If I wrote most things in this way, everyone else would think I was just trying to create artificial job security. Probably the very first reviewer would just reject it instantly and it would never even get started down that path. (unless a compelling justification could be demonstrated, and for most things there is no such justification) I'm not denying this is cool. I like it too. I'm only saying that the upx consideration doesn't matter, because that's an application concern while this is more like theoretical research, and because it's not even the only problem with using code like this in your average real project.
        CyberDildonics 3y ago
        The point was only that far fewer people can work on assembly No one is thinking that is anything other than a demonstration that it can be done in a few hundred bytes. But it is possible to make software with C++ and other languages and actually start at 100KB or less.
VikingCoder 3y ago
The entire Turbo Pascal 3.02 executable--the compiler and IDE--was 39,731 bytes. That's smaller than all but five of these "hi!" executables. https://prog21.dadgum.com/116.html https://prog21.dadgum.com/116.html
- agumonkey 3y ago
  TP5.5 was 800kB IIRC which is still a magnificent bargain IMO
- jenadine 3y ago
  They had good reasons to optimize for size at the time. Today's tradeoff are different. For example, the computer architecture is now 64bit while it was probably 16bit at the time, so all addresses are 4 times as big and much of the data. The compiler optimize first for speed than for size. For example by vectorizing loops but that means the compiler generate several copies of the loop. Since there are more space to spare we also enjoy some more debug data. Also programmer time is more valuable than a few kB saved of the binary.
  - citrin_ru 3y ago
    There is still a reason to optimise for size in some cases - CPU cache is small (compare to RAM) and small code has less cache misses (for instruction cache).
boberoni 3y ago
For those curious about Zig, I compiled (Zig version 0.10.1) the following source code: const std = @import("std"); pub fn main() !u8 { const stdout = std.io.getStdOut().writer(); try stdout.print("hi!\n", .{}); return 0; } ...using the following compiler flags: zig build-exe main.zig -target x86_64-linux -O Debug #=> 965k zig build-exe main.zig -target x86_64-linux -O ReleaseSafe #=> 788k zig build-exe main.zig -target x86_64-linux -O ReleaseFast #=> 695k zig build-exe main.zig -target x86_64-linux -O ReleaseSmall #=> 9k Zig with "-O ReleaseSmall" optimizations creates a 9k binary, putting it at 5th place on OP's chart.

Related: https://pablotron.org/2022/03/02/tiny-binaries-redux/ https://pablotron.org/2022/03/02/tiny-binaries-redux/

Hello world in rust starts at 2.5 MB ? That's disgusting. With C++ and FLTK you can draw a GUI window that says hello world with your static binaries starting at 100KB

joseluis 3y ago
That must be without stripping. Also there are ways to reduce binary size. See e.g. [min-sized-rust](https://github.com/johnthagen/min-sized-rust https://github.com/johnthagen/min-sized-rust). I've gotten stripped binaries of small cli utils less than 400KiB without doing anything special, less than 150 KiB by customizing profile settings and compressing with upx, and less than 30 KiB by replacing the std with the libc as the link shows. Haven't tried with fltk though...
- cinntaile 3y ago
  UPX compressed files used to get flagged by antivirus software, is that not the case anymore?
  - Brian_K_White 3y ago
    I think practical/application issues are out of scope here as this is more like an academic study of a single dimension. upx being acceptable or not is no different than how none of the best performing examples here would be acceotable in most situations either, not just the upx ones, just for other reasins. No company making a random app that didn't have a critical need for this metric would tolerate you writing it in assembly or even c with muscl etc instead of something everyone else can maintain.
    - CyberDildonics 3y ago
      uTorrent took over an entire market segment by being super fast and small. Some people value fast and small software when it happens, there is no reason to accept ridiculous bloat like rust needing multiple megabytes to print a string to stdout. This is just a reminder of how much nonsense languages like rust are packing into their binaries without regard for the people using them.
      - Brian_K_White 3y ago
        No argument. The point was only that far fewer people can work on assembly, and far fewer want to live within the limits imposed by things like muscl. They all expect to code in high level magic environments just like their huge ides with language servers, and their bosses expect a level of productivity that requires that too. If I wrote most things in this way, everyone else would think I was just trying to create artificial job security. Probably the very first reviewer would just reject it instantly and it would never even get started down that path. (unless a compelling justification could be demonstrated, and for most things there is no such justification) I'm not denying this is cool. I like it too. I'm only saying that the upx consideration doesn't matter, because that's an application concern while this is more like theoretical research, and because it's not even the only problem with using code like this in your average real project.
        CyberDildonics 3y ago
        The point was only that far fewer people can work on assembly No one is thinking that is anything other than a demonstration that it can be done in a few hundred bytes. But it is possible to make software with C++ and other languages and actually start at 100KB or less.

VikingCoder 3y ago

The entire Turbo Pascal 3.02 executable--the compiler and IDE--was 39,731 bytes. That's smaller than all but five of these "hi!" executables. https://prog21.dadgum.com/116.html https://prog21.dadgum.com/116.html

agumonkey 3y ago
TP5.5 was 800kB IIRC which is still a magnificent bargain IMO
jenadine 3y ago
They had good reasons to optimize for size at the time. Today's tradeoff are different. For example, the computer architecture is now 64bit while it was probably 16bit at the time, so all addresses are 4 times as big and much of the data. The compiler optimize first for speed than for size. For example by vectorizing loops but that means the compiler generate several copies of the loop. Since there are more space to spare we also enjoy some more debug data. Also programmer time is more valuable than a few kB saved of the binary.
- citrin_ru 3y ago
  There is still a reason to optimise for size in some cases - CPU cache is small (compare to RAM) and small code has less cache misses (for instruction cache).

boberoni 3y ago

For those curious about Zig, I compiled (Zig version 0.10.1) the following source code: const std = @import("std"); pub fn main() !u8 { const stdout = std.io.getStdOut().writer(); try stdout.print("hi!\n", .{}); return 0; } ...using the following compiler flags: zig build-exe main.zig -target x86_64-linux -O Debug #=> 965k zig build-exe main.zig -target x86_64-linux -O ReleaseSafe #=> 788k zig build-exe main.zig -target x86_64-linux -O ReleaseFast #=> 695k zig build-exe main.zig -target x86_64-linux -O ReleaseSmall #=> 9k Zig with "-O ReleaseSmall" optimizations creates a 9k binary, putting it at 5th place on OP's chart.