Hacker News Reader

Comment by userbinator | Hacker News Reader

The size comparisons are also very useful, if anything to show that even the simple "non-Modern" C++ program already has quite a bit of bloat.

Compilation takes 0.064 seconds, produces 8480 byte executable

I am experienced with Asm so I can come up with an instinctive order-of-magnitude estimate, but even those who aren't should try to roughly estimate how many machine instructions are required to implement that code, and come to the conclusion that over 8000 bytes for three nested loops with not much in them, a comparison, some arithmetic, and a handful of library function calls seems rather excessive. Even 800 would be on the high side --- somewhere around 100-200 bytes is my estimate.

Also, watch this 4k demo (everything you see and hear is generated in realtime by a 4096-byte executable):

https://www.youtube.com/watch?v=jB0vBmiTr6o

View on HN

The 8480 includes bytes used for names of external symbols, etc.

otool tells me the assembly routine is 74 instructions (279 bytes, if I’m counting correctly)

I don't think that this is a very meaningful comparison at these sizes, because it entirely depends on your target. Just compiling a "foo.c" file with "int main() { }" for sole content through "gcc -Os" produces a 16kb executable on my linux machine, but I know very well that the exact same compiler will produce something much smaller if I compile for, say, a bare metal AVR target because the ELF file format has a lot of fluff.

> because the ELF file format has a lot of fluff.

I wouldn't call it fluff: even assuming no debugging info (which you won't have in your avr object file) it has info needed at runtime (program start time) such as where to load what into memory, how much initial uninitialised memory to allocate when starting up, etc. It all gets used.

I think the keyword might be an 8k executable, not 8k of code. If I compile the example with clang on my box (linux x86_64) I get a 17K executable, for which the .text section (containing pretty much the runnable code)is 0x291 (661) bytes with the debug build and 0x255 (597) bytes with -O3.

If I dig into the .text segment of the optimized executable, only 235 bytes belong to the main function (others are stuff like __libc_csu_init and register_tm_clones). Looking at the assembly the loop would be about 123 bytes.

So lots of overhead, but I wouldn't say it is in the nested loop.

I abandoned C++ and Windows programming in 1996 to focus on hardware and firmware. So I'm rather familiar with just straight C and keeping code size down.

You have to be careful, a lot of those 8000 bytes might well be printf().

You have to be careful, a lot of those 8000 bytes might well be printf().

If it was a statically linked executable, it would be far bigger than 8K.

It's probably a few kilobytes of symbols, a few kilobytes of crt0, some ELF overhead, and a few hundred bytes of user code.

man size

https://linux.die.net/man/1/size

Reply on news.ycombinator.com