Hace unos meses, a raíz de un correo de Jesús Sanz comentando la mítica entrevista a BJarne Stroustrup , hicimos una pequeña prueba de cuánto podría engordar un “Hola, mundo!” en función del compilador y lenguaje de programación que utilices. De la exageración -casi irreal hoy en día- de 2.1 MB de ejecutable que prácticamente no hace nada (digo “casi irreal” porque he visto ejecutables que no hacían prácticamente nada más que lanzarse a ejecución con lorzas de bytes similares a esas), llegamos a los 177 bytes de “Hola, mundo!” (aunque estoy convencido de que se puede rebajar bastante más, y no me refiero a usar el formato COM, lenguajes interpretados o trucos similares ).

Veamos cómo fue la “operación bikini” con nuestros programas…

Todo comenzó con una frase de neo2001 que decía incrédulo: “De todas maneras… por morbo y porque me parecía una pasada, he compilado un helloWorld con el gcc 4.0 (creo) de Xcode y ocupa 38.796 bytes el binario… no 2.1 MB como dice este señor… vamos, no se a que se referirá…. pero creo que no se sostiene“.

Es una broma… que da qué pensar, ¿eh?

¿38.796 bytes un helloWorld y te parece poco? El mundo está loco.

Lo mismo en C ocupa…

$ echo 'main() { printf("Hello, world\n"); }' > helloC.c

$ make helloC
cc     helloC.c   -o helloC

$ ls -l helloC
-rwxr-xr-x 1 txipi txipi 6922 2006-05-28 00:19 helloC

6922 bytes, 6 veces menos!!

Pero es que si lo hacemos en ASM…

$ cat helloASM.asm
extern printf, exit

section .text

global _start
_start:

   push dword formatstring
   call printf
   push 0
   call exit

section .data

formatstring: db "Hello, world",10,0

Lo ensamblamos…

$ nasm -f elf helloASM.asm -o helloASM.o
$ ld -s --dynamic-linker /lib/ld-linux.so.2 -lc helloASM.o -o helloASM

Y lo ejecutamos…

$ ./helloASM
Hello, world

Miramos cuanto ocupa…

$ ls -l helloASM
-rwxr-xr-x 1 txipi txipi 1412 2006-05-28 00:25 helloASM

Ocupa 1412 bytes, unas 5 veces menos que en C y unas 30 veces menos que en C++.

Pero si es que en lugar de usar funciones de C como printf usamos las llamadas al sistema, nos ahorramos algo de espacio…

$ cat helloSyscalls.asm
section .text

global _start
_start:

   mov  eax, 04h
   mov  ebx, 01h
   mov  ecx, formatstring
   mov  edx, 13
   int  80h

   mov  eax, 01h
   mov  ebx, 00h
   int  80h

section .data

formatstring: db "Hello, world",10,0

Lo ensamblamos, enlazamos y ejecutamos…

$ nasm -f elf helloSyscalls.asm -o helloSyscalls.o
$ ld helloSyscalls.o -o helloSyscalls
$ ./helloSyscalls
Hello, world

Miramos cuanto ocupa…

$ ls -l helloSyscalls
-rwxr-xr-x 1 txipi txipi 811 2006-05-28 00:30 helloSyscalls

¡Aproximadamente la mitad que antes!

Pero aún hay más, si le pasamos el sstrip, para quitar secciones y strings que no sirven en tiempo de ejecución…

$ sstrip helloSyscalls
$ ls -l helloSyscalls
-rwxr-xr-x 1 txipi txipi 177 2006-05-28 00:35 helloSyscalls

177 bytes!!!

Frente a los 39 KB de C++, hay diferencia

Posteriormente, entre los contertulios del hilo de correos, hicimos una recopilación de nuestras indagaciones, bastante reveladoras:

• Windows Borland C++ Builder: 311.296 bytes
• g++ 4.0 de Xcode (C++): 38.796 bytes
• Borland 3.1 con cout (C++): 23.798 bytes
• Borland 3.1 con printf (C): 8.992 bytes
• gcc 4.0 (C): 6.922 bytes
• nasm con printf: 1.412 bytes
• nasm con syscalls: 811 bytes
• nasm con syscalls, stripped: 177 bytes

311296 frente a 177 bytes, ¡¡¡un factor de “compresión” de 1758 a 1!!! (ya, ya, es un ejemplo farsa, pero me gusta poner voz de vendedor de teletienda ).