C Memory usage competition of the famous "hello world"

Spartrekus

Spartrekus

Hello,

After Clang, GCC,... and more, I would like to discuss about a simple hello world and how much memory usage it may take.

Herewith the example:
Code: 
#include <stdio.h>
int main()                                                                                                    
{
   do
   {
     puts("Hello World\n");
   } while (getchar() != EOF);
 
   return 0;                                                                                            
}

Code: 
CPU:  5.2% user,  0.0% nice,  1.8% system,  0.0% interrupt, 93.0% idle
Mem: 83M Active, 70M Inact, 166M Wired, 97M Buf, 585M Free
Swap:

  PID USERNAME    THR PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
1350 spartrekus       5  29    0   105M 47796K CPU2    2   1:11  19.76% Xorg
1616 spartrekus       1  22    0 24384K 13064K select  3   0:01   5.66% xterm
1373 spartrekus       1  20    0 12080K  2600K nanslp  0   0:02   0.38% naclock
1631 spartrekus       1  20    0 13916K  3808K CPU3    3   0:00   0.34% top
1626 spartrekus       1  20    0 10652K  2160K ttyin   2   0:00   0.20% hellogt
1629 spartrekus       1  20    0 22992K 11360K select  0   0:01   0.13% xterm
1378 spartrekus       1  20    0 12024K  2624K nanslp  2   0:01   0.10% nclock
1570 spartrekus       1  20    0 25492K 14240K select  1   0:04   0.07% xterm
1376 spartrekus       1  20    0 22948K  9368K select  3   0:01   0.06% xterm
1361 spartrekus       1  20    0 22948K  9256K select  3   0:01   0.04% xterm
1607 spartrekus       1  20    0 15952K  6096K select  0   0:02   0.03


The uname returns : FreeBSD Generic 12.0-CURRENT with r328637

On my machine, compiled with gcc, top gives about 10652K 2160K. How much you have (and which compiler)? Quite a lot actually.
(the machine is: RPI3 model b, with FreeBSD running at full speed with evilwm as main WM, with Xorg and evilwm (my personal config).

Ideally, for good comparison, we should compare this with assembly.
 
Shouldn't the platform's C library consume most of the memory here? So, a comparable asm implementation should use this C library as well (instead of direct syscalls).

Btw, suggest the following code instead:

Code: 
#include <stdio.h>
int main()                                                                                                    
{
   do
   {
     puts("Hello World\n");
   } while (getchar() != EOF);
 
   return 0;                                                                                            
}
 
obsigna said:
There is no VIRT output column in the top(1) command of FreeBSD. Go and discuss your results on a Linux forum of your choice.
Click to expand...

In most cases, clang produces smaller files compared to gcc.

I fixed the issue. top gives about 10652K 2160K (compiled with gcc on freebsd 12) and it gives 10784K 2228K with clang.
 
Spartrekus said:
In most cases, clang produces smaller files compared to gcc.

I fixed the issue. top gives about 10652K 2160K (compiled with gcc on freebsd 12) and it gives 10784K 2228K with clang.
Click to expand...
So you are trying to make a case for (10784-10652)/10784*100 = 1,2 % difference of the total size of the hello process (text, data, and stack)? We cannot even tell if this is because the used shared libraries got different functionality in total. The difference might be caused by different memory alignment schemes. Perhaps, you didn't strip the symbols from the binaries, did you? Clang might put more descriptive meta data for facilitate debugging into the code.

IMHO, this approach does lead you directly into the middle of nowhere. Compare the binary size, utilizing useful compiler flags and that's it.

Your example on a BeagleBone Black ARMv7 FreeBSD 12.0-CURRENT (GENERIC) #0 r333409:
clang -g0 -O3 hello.c -s -o hello
Size of the binary is 4251 bytes.
 
Fascinating, but totally irrelevant. A: The memory usage of a program that has about 3 executable lines is not a good predictor of the memory usage of real world programs that solve real world problems (like editing files, calculating numbers for spread sheets, hunting monsters in dark alleys, ...). B: What you are really measuring is how all the libraries are loaded, and whether they are being shared or not. Just by changing compile and link options, I can change the memory usage by several orders of magnitude, so the about 10% difference you see between gcc and clang means nothing.

Here is a suggestion for a meaningful experiment: Find a program that does something useful. For example, I was running a mp3 encoder earlier today (lame), because I was ripping a CD for listening to in my office later. Lame actually uses a lot of CPU time, and quite a bit of memory. Or sometimes I have to crop, shrink and jpg-encode pictures, to post cute pictures of our family on the web site so relatives can see them; the various ppm... tools and cjpeg actually use CPU and memory. Then compile the program *and all the libraries* with either gcc or clang, and measure the difference in total memory consumption of the system under realistic operating conditions (whatever is realistic for your system). One easy way to do this would be to run the same task on both Linux (which usually uses gcc), and FreeBSD (which usually uses Clang/LLVM).
 
Well, I can run up a DOS 6.22 virtual machine with 1M of RAM (can't go any less) and fire up my old trusty Turbo C 1.0 and guarantee that "hello world" takes a lot less than whatever was mentioned above. Or maybe I should do it in asm?

What's the point? Bloat is like Moore's Law.
 
Datapanic said:
Well, I can run up a DOS 6.22 virtual machine with 1M of RAM (can't go any less) and fire up my old trusty Turbo C 1.0 and guarantee that "hello world" takes a lot less than whatever was mentioned above. Or maybe I should do it in asm?

What's the point? Bloat is like Moore's Law.
Click to expand...

Hi You are interesting me a loooooooooooooooooot

FreeBSD claims that CLANG Is Magic, nothing of Bloat, just perfection.
Since BSD and Linux use the same magic bloats (compilers,...) both systems aren't much different to me.

400k is quite much

wanna listen to your mem results of hello world in turbo C...

--
@rasphbsz I do not agree with your just above posted post.
 
ronaldlees said:
Probably want to compare individual obj files rather than final executable, to determine compiler efficiency.
Click to expand...

It is quite difficult to compare things, apples and pears... in any cases. It will give also a different size depending on op. systems, cpu,...
 
Spartrekus said:
In most cases, clang produces smaller files compared to gcc.

I fixed the issue. top gives about 10652K 2160K (compiled with gcc on freebsd 12) and it gives 10784K 2228K with clang.
Click to expand...
What again was the issue which you fixed?

The SIZE column of top(1) shows the total size of memory (text, data, and stack) which the OS has attributed to the process and RES is the part which actually resides in RAM. Programs are usually linked against shared libraries provided by the system, and of course these add to the total memory occupation as well - and compared to this, the size of the hello binary itself is neglectable. So the differences in the respective values which you reported for GCC and Clang are most probably related to different functionalities of the shared libraries which had been linked-in by the different compilers.

The figures of your hello source built on my BeagleBone Black FreeBSD 12-CURRENT (ARMv7) using clang -g0 -Os hello.c -s -o hello are:
Binary: 4252 byte
SIZE: 4276K
RES: 1968K

I won't install GCC here, even if a reduction of total memory occupation of (10784 - 10652)/10652*100 = 1,2 % would be guaranteed all over the place - which I hardly believe. A difference of 1.2 % may easily change for real world executables in the one or the other direction.
 
To whom it may concern: good ol' stormc for 68030 comes in at 15kB, that is a static link. Running it will not be over 20kB.
 
x86_64 assembly binary is 512 bytes.
Code: 
section .data
h db 'Hello, World!', 0
section .text
global _start
_start:
    mov     rax, 4
    mov     rdi, 1
    mov     rsi, h
    mov     rdx, 13
syscall
    mov     rax, 1
    xor     rdi, rdi
syscall

#nasm -f elf64 hello.asm
#ld -s -o hello hello.o
 
You must log in or register to reply here.
Back
Top