>If you compile hello world in C, it's not going to be very big either.

You should actually try that, and compare sizes with the asm hello world.

The problem not in the language per se, but in the linker settings. By tweaking it, you can achieve almost same size as the assembler version has.

You say that, but I still haven't seen any compilers link in only parts of libc. Use any of it and it all comes in.

Hello world in C becomes anywhere from 120KB to 1.2MB even if just using puts. Even setting the entry point to a function with no arguments doesn't help.

A tiny hello world ends up needing to ignore the standard library and use a console output function from the OS.

Just checked on a Ubuntu machine. Hello world takes 6Kb. Uses printf.

That's because it links dynamically to the standard library.

Is that a problem? It's there whether you use it or not, and it's not like the asm is running in a vacuum either.

If you go to an embedded point of view where there is nothing already supplied, you can get a hello world, even with a basic printf, down to that size.

Especially since you use external libraries to do the bulk of the work, 6KB is a lot.

It is an order of magnitude bigger than the assembly version.

After some manipulations with the linker, I was able to cut the size down to 750 bytes. You cannot go below this, without hacking the ELF file format.

I got my asm one down to 268 without even trying.

It prints (via write syscall) "hello world.\n" and then calls exit(0).

Assembled with fasm, linked with ld -n, then stripped.

Ok fine, I've used the tool called sstrip from a suite called ELFKickers. Now my hello_world.cpp (yes, c++) is 380 bytes long. I could not make it any shorter, so yeah, it is 120 bytes (50%) bigger than yours.

Regarding sstrip, I am familiar with it. Be careful that you know what it actually does.

So, not order of magnitude then?

Yes, just look into how much effort you had to put vs my five minutes attempt.

The difference is between just using asm, or going out of the way to try to coerce a C toolchain to minimize the bloat.

Yea, large effort (objcopy, strip, sstrip), that I need to do only once, after that I already know how to do this an can just put it in a shell script. Now, I would like to know how quickly you'll be able to write a quicksort implementaion, that would outperform my C code, while being at least 25% smaller . Yeah, and how big your binary will become, once you link libc or opengl or whatever to make it able to do actual work.

95KB using MinGW's GCC on Windows using default compilation.

When I tell it to emit the assembly with "-S" I get 28 lines of code when I have a feeling assembly is much shorter.