Cómo escribir un JIT de 5 μs con IA y ARM64

Por qué un JIT de 5 μs cambia el cálculo de los databases

La mayoría de databases con compilador JIT usan LLVM o emiten C/C++, y eso les deja tiempos de compilación demasiado altos para aplicarlos a cada query. Un post reciente de Myles Isaksen demostró que, asistido por IA, se puede escribir un JIT que compila código en ~5 μs y genera assembly ARM64 directamente para poder ejecutar cada query, no solo un subconjunto. El ejemplo concreto es pgrust, un database embebido en Rust cuyo JIT se compila en alrededor de 5 microsegundos y termina igualando el rendimiento de la versión escrita a mano (en el regex de prueba, el JIT quedó a la par del código hecho a mano: ~3,8 ns en la entrada más corta y ~470 ns en 2.049 bytes).

Qué demuestra el benchmark del JIT y qué no

Los números del post son sobre un ejemplo pedagógico (un motor de regex para b(an)*), así que hay que leerlos como demostración del método, no como benchmarks de un database de producción. En esa prueba el intérprete sale entre 11,7x y 19,7x peor que el JIT, y el JIT termina empatado o ligeramente por delante de la versión codificada a mano. Esa segunda parte es la que importa: que un emisor genérico construido con stencils de assembly duplique, casi, el rendimiento del código handwritten es señal de que la barrera de entrada al JIT descendió, no de que ya reemplazó a LLVM.

El método: stencils, copy-and-patch y mmap ejecutable

El pipeline es directo y vale la pena recorrerlo para founders que montan infraestructura de bajo nivel. Primero se definen stencils: plantillas de instrucciones ARM64 (4 bytes cada una) para operaciones recurrentes — comparar un byte, saltar, bifurcarse, fallar, apilar un par (dirección_de_resume, posición) para backtracking. Luego, un Emitter recorre el AST del regex concatenando stencils y rellenando los huecos con datos concretos (el byte a comparar, la dirección absoluta de la etiqueta de retorno). Finalmente se reserva memoria con mmap (PROT_READ | PROT_WRITE | PROT_EXEC y, en macOS, MAP_JIT), se copia el buffer de instrucciones y se invalida el i-cache. El resultado se transmutacióna a un fn y se llama como cualquier función. Sobre macOS/ARM64, el ejemplo gira alrededor de los registros x0 (puntero al input), x1 (puntero al stack), x2 (base del stack) y x9 como temporal; la cadena se pasa terminada en \0 para eliminar las comprobaciones de longitud. Detalles como los bit-fields de las branch (0x54000001 | offset, con offset en bits 5..24) son donde la asistencia de IA marca la diferencia: el propio autor reconoce que su única experiencia previa con assembly era el CTF microcorruption.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Qué cambia para tu startup

Para un founder tech, la conclusión no es "tengo que escribir un JIT": la conclusión es que el costo de tener componentes de bajo nivel optimizados a medida cayó. Tres implicaciones inmediatas.

Productizar el cuello de botella. Si tu database embebido, motor de reglas o parser de esquemas compila en cada request y tarda demasiado, un mini-JIT estilo stencil puede ser 10–20x sobre el intérprete sin meterse con LLVM ni con C++. Para una librería que ya conocés en Rust, el patrón (stencils + Emitter + mmap ejecutable) es portable: el post se queda en ARM64, pero el esqueleto es CPU-agnóstico.
Renegociar la decisión de "comprar LLVM". Las bases con JIT propio (CockroachDB, los derivados de Postgres que usan LLVM) arrastran tiempos de compilación altos. Cuando el cuello de botella es el compile time, una opción más liviana puede entrar en presupuesto: cada query, no un subset.
Reenfocar a los LLMs donde sí ayudan. El meme "el código nunca fue lo difícil" aplica a CRUD con un framework, pero no aplica a código de sistemas. Para un founder, eso se traduce en: usá IA donde rompe barreras (assembly, optimización bitwise, FFI), no donde ya es commodity.

Acciones concretas que podés aplicar esta semana

Mide primero. Antes de escribir un JIT, instrumentá tu query path con contadores por fase (parse, optimize, compile, execute). Si el compile pesa más del 20% y los queries son repetitivos, hay caso de negocio.
Replica el ejemplo. El patrón completo del post (stencilprologue, stencilchar, stencilsplit, stenciljmp, stencilmatch, stencilfail + Emitter) cabe en un crate chico. Armá un crate interno con un benchmark contra tu hot-path actual; incluso si los números no cierran, tenés un marco para decidir.
Cuida el W^X. En macOS usá MAP_JIT con los pares pthread_jit_write_protect_np que muestra el post. En Linux, mmap con PROT_READ|PROT_WRITE para escribir y luego mprotect a PROT_EXEC. Es el detalle que olvidan los MVP y luego cuesta un CVE.