Bun se reescribió de Zig a Rust en once días. Medí las cinco cifras que publicaron

Un proyecto grande anunció que había reescrito su base de código entera en otro lenguaje, y publicó cinco números para demostrar que había salido bien. Los números eran buenos. Demasiado redondos, además: cinco veces menos CPU, la mitad de memoria, el doble de velocidad al arrancar.

La reescritura en sí me interesaba poco. Me quedé con otra cosa: las dos versiones se pueden descargar. La 1.3.14 fue la última construida en Zig y la 1.4.0 la primera construida en Rust, con el mismo servidor corriendo encima y el mismo sistema debajo. La única variable que cambia es el binario. Eso convierte un anuncio en algo comprobable, y comprobarlo cuesta una tarde.

Así que descargué las dos y medí las cinco cifras.

Qué es Bun y por qué esto es medible

Bun ejecuta JavaScript y TypeScript, el mismo papel de Node, dentro de un binario único que además trae gestor de paquetes, empaquetador y corredor de pruebas. Se vende como reemplazo directo de Node.

El proyecto describe la traducción como once días de trabajo intensivo sobre unas 535.000 líneas de Zig, y publica un desglose de cómo lo organizó. Ese proceso da para otra conversación entera. Lo que me interesa aquí es más estrecho y más comprobable: el binario resultante hace lo que dicen que hace.

Las cinco cifras publicadas son estas: arranque un 50% más rápido en Linux, cinco veces menos CPU en reposo, 48% menos memoria en servidores HTTP, entre 2% y 5% más peticiones por segundo, y cerca de un 20% menos de tamaño de binario.

El montaje, y por qué el primer intento no servía

Las dos versiones van a directorios separados, sin tocar ninguna instalación que ya funcione:

for V in 1.3.14 1.4.0; do
  curl -fsSL https://bun.sh/install | BUN_INSTALL=$PWD/i-$V bash -s "bun-v$V"
  cp $PWD/i-$V/bin/bun $PWD/bin/bun-$V
done

El primer dato sale de ahí, sin ejecutar nada: 92,75 MB el binario en Zig, 80,76 MB el binario en Rust. Un 12,9% menos. El proyecto habla de cerca de un 20%, y la diferencia probablemente esté en qué se pesa exactamente; el número de arriba es el binario que baja de su instalador, medido con ls.

El servidor de prueba es el mismo para los tres candidatos, sin dependencias ni framework encima, porque cualquier librería sería una variable que no controlo:

const handler = () => new Response("hola", {headers: {"content-type": "text/plain"}});

if (typeof Bun !== "undefined") {
  Bun.serve({port: puerto, fetch: handler});
} else {
  require("http").createServer((req, res) => {
    res.writeHead(200, {"content-type": "text/plain"});
    res.end("hola");
  }).listen(puerto);
}

Y aquí viene el primer tropiezo, que vale más que varias de las mediciones.

Las cinco cifras, medidas

Todo en la misma máquina, un Ryzen 7 7800X3D con 30 GB de RAM, en CPU. El servidor fijado a dos núcleos con taskset y el generador de carga a otros seis, para que no compitan por el mismo planificador: si compartieran núcleos, estaría midiendo cuál de los dos pierde la pelea.

anuncio de bun 1.4 · contra mi banco de pruebas

2/ 4se sostienen al medirlas

Arranque en frío, en Linuxse sostiene

dicen 50% más rápido

61,4% más rápidoDe 7,58 ms a 2,93 ms, mediana de las 60 corridas del gráfico de abajo.

CPU en reposose sostiene

dicen 5x menos

9,3x menosEn 300 segundos: 216,19 ms de CPU contra 23,18 ms. Repetido, el múltiplo se mueve entre 8,8 y 13,8.

Memoria de un servidor HTTPno llega

dicen 48% menos

38,2% menosDespués de atender tráfico. Recién levantado el proceso sí llega al 55,5%, así que el número depende de cuándo se mire.

Tamaño del binariono llega

dicen 20% menos

12,9% menosDe 92,75 MB a 80,76 MB, pesando el binario que baja del instalador oficial.

La marca gris de cada barra es lo que promete el anuncio; la barra es lo que salió al medirlo. Falta una quinta fila, la de peticiones por segundo: la retiré al descubrir que el servidor y el generador compartían núcleos físicos. Se explica más abajo.

El arranque es real y es enorme

Es la diferencia más grande de todas, y la más fácil de comprobar: ejecutar un archivo con un console.log y cronometrar.

arrancar y ejecutar una línea · 60 corridas cada uno · ms

bun 1.4.0 · Rust2,93ms

La nube más apretada de las tres: 2,85 a 3,10 ms.

bun 1.3.14 · Zig7,58ms

node 22.23.215,81ms

061218

Las 60 corridas de cada candidato, en ms

candidato	mediana	mínimo	máximo
bun 1.4.0 · Rust	2,93	2,85	3,10
bun 1.3.14 · Zig	7,58	7,45	8,63
node 22.23.2	15,81	14,78	18,07

Las corridas caen en el orden real en que se ejecutaron, y la mediana se recalcula con cada una. Las tres nubes terminan sin tocarse: cuando la separación es así de limpia, la diferencia es del programa y no de una corrida afortunada.

Un 61,4% más rápido sobre este caso, contra el 50% que anuncian. Con una salvedad: esto es un console.log con el binario ya en la caché del sistema. No ejercita módulos, ni resolución de dependencias, ni transpilación, y esas son justo las etapas que un arranque real sí paga. Y el binario en Rust es además el más estable de los tres: sus sesenta corridas caben en 250 microsegundos, mientras que Zig tiene un pico suelto de 8,63 ms y Node uno de 18,07.

Esa estabilidad es la razón de publicar la mediana y no el promedio. Un solo pico del planificador arrastra un promedio entero, y en una máquina compartida siempre hay uno.

La CPU en reposo no se puede medir con las herramientas obvias

Aquí me equivoqué de instrumento antes de acertar. Un servidor levantado y sin nadie pidiendo nada debería consumir prácticamente cero, y eso es justo lo que hace difícil medirlo.

La primera pasada usó los contadores de /proc/<pid>/stat, que cuentan en tics de diez milisegundos. Sobre trescientos segundos dio ocho tics para Zig y un tic para Rust. Dividir eso arroja «ocho veces menos», que suena a resultado. No lo es: con un tic de resolución no se distingue «ocho veces menos» de «nada medible», y Node en esa misma pasada dio cero tics, o sea infinito.

La herramienta correcta es /proc/<pid>/schedstat, que expone el tiempo en CPU en nanosegundos, seis órdenes de magnitud mejor, y suma todos los hilos del proceso:

def ns_cpu(pid):
    """Nanosegundos de CPU del proceso, sumando todos sus hilos."""
    total = 0
    for tid in os.listdir(f"/proc/{pid}/task"):
        total += int(open(f"/proc/{pid}/task/{tid}/schedstat").read().split()[0])
    return total

Con esa resolución el número aparece limpio, y es el más favorable de los cinco.

schedstat · CPU acumulada de un servidor ocioso · 300 s

215,1bun 1.3.14 · Zig

22,2bun 1.4.0 · Rust

150 s

levantado5 min

bun 1.3.14 · Zig · 215,1 msgasta CPU en los 299 segundosbun 1.4.0 · Rust · 22,2 mssolo en 47 de 299

Nadie le pide nada al servidor en estos cinco minutos. La curva de Zig sube en todos y cada uno de los 299 segundos; la de Rust se queda plana y da 47 escalones sueltos. El total importa menos que la forma: uno se despierta sin parar y el otro duerme de verdad.

Nueve coma tres veces menos, contra las cinco que anuncian. Pero el total es lo menos interesante del gráfico.

Lo que se ve al reproducirlo es que las dos curvas tienen forma distinta. La de Zig es una rampa: sube en los 299 segundos, sin saltarse ninguno. La de Rust es una escalera casi plana, con 47 escalones en toda la ventana. Rust no abarata cada despertar. Se despierta seis veces menos.

Esta es la única cifra que no medí en la misma máquina que el resto. A media tarde la máquina de pruebas volvió a llenarse de trabajo ajeno, y el reposo es precisamente lo más sensible a eso: un proceso ocioso en una máquina saturada se despierta más veces por contención y acumula CPU que no es suya. Los números de aquí salen de un servidor de cuatro núcleos con carga 0,05, donde medir un proceso dormido no molesta a nadie.

Y hay que decir algo sobre la precisión del múltiplo. Repetí el experimento tres veces y dio 8,8, luego 13,8 y luego 9,3, en la misma máquina y con el mismo método. Cuando el numerador y el denominador son ambos diminutos, la razón entre ellos baila. El múltiplo exacto no es un dato firme; que supere las cinco veces anunciadas, sí, porque eso se sostuvo en todas las corridas.

Vale una aclaración honesta: los dos consumen una cantidad de CPU irrelevante en reposo. Doscientos dieciséis milisegundos en cinco minutos no le arruinan el día a nadie. Donde esto importa es al multiplicar por cientos de procesos, que es exactamente el caso que el proyecto menciona.

La memoria mejora, pero no tanto como dicen

$ cat /sys/devices/system/cpu/cpu10/topology/core_cpus_list
2,10
$ cat /sys/devices/system/cpu/cpu11/topology/core_cpus_list
3,11