Diseñando el sistema de consultas de Krabby: objetivos y arquitectura

Fuentes: Designing a query system for Krabby

El autor describe el proceso de cinco meses para diseñar el sistema de consultas del compilador Krabby, inicialmente planteado con una arquitectura push que acabó descartada. Las principales limitaciones del modelo push eran que, al gestionar referencias pendientes, terminaba siendo un sistema de consultas encubierto; su naturaleza perezosa desaprovechaba la caché de CPU; no resolvía bien cadenas largas de dependencias en paralelo; y dificultaba priorizar objetivos concretos, algo esencial para integrarse con servidores LSP. En su lugar, se opta por un enfoque pull que introduce priorización según demanda.

El nuevo diseño incorpora una lista de características diferenciadoras frente a sistemas como rustc y salsa. En primer lugar, la concurrencia se trata como requisito desde el inicio, distribuyendo tareas entre hilos y gestionando contención y ciclos. En segundo lugar, la asincronía permite que las tareas se pausen y reanuden, lo que habilita dependencias entre hilos, esperas simultáneas a varias tareas (análogas a la concurrencia estructurada), E/S asíncrona y el uso de io_uring en Linux. Para evitar la sobrecarga de async/await de Rust, se plantea una implementación manual de estados asíncronos.

La tercera pieza es el procesamiento por lotes: tareas del mismo tipo se agrupan en tandas (por ejemplo, 64 simultáneamente) para mejorar el uso de la caché de código y habilitar optimizaciones futuras como SIMD o hash tables optimizadas. El autor estima mejoras de entre el 20% y el 40% solo en lookups de tablas hash, gracias a que son operaciones limitadas por memoria y a que la CPU puede ejecutar trabajo útil mientras esperan las lecturas. En conjunto, el sistema se plantea como una base flexible para futuras optimizaciones del compilador.