Comment by weinzierl | Hacker News Reader

Comment by weinzierl | Hacker News Reader

Parent Full thread

A comparison between a fully statically linked native binary and one that loads some or all libraries dynamically would equally be vastly unfair.

I think comparing container images would be a good start. Use the most minimal base image you can get away with, or even "FROM scratch" if possible, but compare only images with the same architecture. I'd prefer 32-bit, to take things like running 32-bit on 64-bit or 64-bit with pointer compression out of the picture.

Then compare the size of the uncompressed exported tar. Probably also not completely fair, depending on what question you want to answer but it takes the obvious variances out of the equation.

EDIT: Thinking about it some more, it might even be more fair to compare maximally compressed image size to account for compression within the container. Of course you'd have to compress with the same algorithm and parameters or just add the decompressors size to the final result like they do in compression benchmarks.

It’s funny because back in the day these were these kind of discussion points thrown around in the Lisp forums when folks would balk at “executable sizes”.

Specifically about how C leverages the “free” runtime of the OS while Lisp has to bundle is own.

This idea of container runtime sizes would be an amusing thread. A good test of something like Nix or Guix to a very fine grain. “We don’t need bash or ls so we removed it. “ “The VM only simulate a single network card, so we’ll scrap all the other driver. “

C doesn't leverage the free run time of the OS, when that OS is Windows. Your hello.exe size has to include the run-time DLL's required for it from the C implementation that was used to build it.

Windows has only recently been moving toward providing a public run-time for C; the "Universal C Run-Time" (UCRT) that has been introduced in Windows 10.

> C doesn't leverage the free run time of the OS, when that OS is Windows.

Stdio, no. Printf, no (unless you’re an adherent of LIBCTINY[1] or one of its descendants[2] and need only a minimal set of features). Malloc, yes—MSVC’s malloc() on Win32 has always been a thin wrapper around kernel32!HeapAlloc. Strlen or memcpy or whatnot—also possibly yes, but it’s not like minimal implementations of those are large anyway.

[1] http://bytepointer.com/resources/pietrek_libctiny_1996.htm

[2] https://www.benshoof.org/blog/minicrt

For some reason, even with the UCRT, binaries seem overly bloated. I've been toying with Zig over the past couple weeks and I really like that it doesn't rely on a C runtime on Windows. Plus it makes it easy to operate entirely with UTF-16 strings, which is a nice to have when I'm writing a utility that is specific to Windows.

The ucrt is included as far back as Windows 7 (if you install updates).

The increment in disk space usage caused by the update has to count toward the effective size of the hello program, experienced by the user of that installation.

.net program on 8bit IOT OS such as contiki [0] would be lot smaller than 32/64 bit OSes. (assuming not requiring use of native 16/32/64 bit routines ).

[0] https://en.wikipedia.org/wiki/Contiki

Reply on news.ycombinator.com