HN Explorer

11 comments

[ 2.2 ms ] story [ 39.2 ms ] thread
lxe
Love this every time it gets posted. Similar vibes to the Justine Tunney's cosmopolitan / αcτµαlly pδrταblε εxεcµταblε world.
mistrial9
this use of greek letters for marketing memorability seems "tone-deaf" to me, in other words, lacking any respect for modern greek
cestith
I can't imagine screen readers do a great job of seeing Greclish and giving visually impaired users a sensible pronunciation, either.
[deleted]
(comment deleted)
nousermane
I guess this was written a fair while ago. On my laptop, even in 32-bit (i686) mode, with gcc-12 and libc-2.34:

- very first, unoptimized program compiles to 15440 bytes (vs 3998 on OP's system);

- super-optimized hand-rolled assembly (tiny.s) compiles to 12780 bytes (vs 368 on OP's system).

Alupis
I'm wondering if our binaries have really bloated this much, or if there was something the old GCC's did that we no longer get "for free".

On my Rocky Linux 8.5 machine with kernel 4.18.x, gcc 8.5.x, and glibc 2.28.x, the sample C program compiles to 17,800 bytes - after stripping, it's down to 6,768 bytes. 16,292 bytes in 32 bit mode, 6,148 after stripping.

To put things in perspective, the AVR ATTiny85 only has 8KB of program memory, meaning this simple "return 42" program wouldn't even fit as-is.

Seems glibc does add a considerable amount of "bloat" to the binary. I wonder what a properly "golfed" ELF binary file size would be today?

nousermane
I think large chunk of it is from dynamic linker, rather than glibc. At least that appear to be the case according to "file a.out". Adding "-static" option seems to prevent that:

  $ gcc -Wall -s -nostdlib tiny.o; wc -c a.out
  12780 a.out

  $ gcc -Wall -s -nostdlib tiny.o -static
  $ wc -c a.out
  4304 a.out
Bulk of what remains is page-size alignment. Linux works with 4KB pages:

  $ getconf PAGESIZE
  4096
...so it makes sense that gcc (ld, really) aligns to that. But we can dial it down:

  $ gcc -Wall -s -nostdlib tiny.o -static \
     -Wl,-zmax-page-size=64; wc -c a.out
  400 a.out
...and a bit more could be shaven by dropping Build ID:

  $ strip -R .note.gnu.build-id a.out; wc -c a.out
  344 a.out
This wonderful piece of software: https://github.com/aunali1/super-strip seem to find more things to remove, although not sure what would be that:

  $ sstrip a.out; wc -c a.out
  220 a.out
Of course, this is not quite "golfed", and I too, would love to see OP's article updated to x86_64 and current crop of gcc/binutils.
Alupis
Not quite 45 bytes, but 12,780 bytes down to 220 (a 98% footprint reduction) is very impressive on it's own.