tsbootstrap fue hasta 20x más rápido al mover menos bytes

El motor de bootstrap de tsbootstrap se volvió drásticamente más rápido tras un rediseño centrado en una regla simple: no materializar un array si su único consumidor es una reducción. Según los resultados de benchmark del proyecto, ahora cada casilla de la comparativa directa favorece la ruta fusionada, con ganancias de 3.1x a 20x en series más largas. En el caso más persistente, el tiempo de ejecución cayó de 13.1 ms a 0.55 ms después de que el equipo eliminara objetos semilla construidos en Python.

El cambio llegó después de que una comparación directa con arch, una biblioteca de econometría consolidada, expusiera un problema que los benchmarks internos de regresión de tsbootstrap habían pasado por alto. En una carga de trabajo realista —algunas miles de réplicas de series de unos pocos miles de puntos— tsbootstrap era varias veces más lento de punta a punta. El autor dice que todas las versiones anteriores se habían lanzado con ese déficit.

En el centro de la ralentización había un diseño por lotes con NumPy que construía todas las réplicas de bootstrap a la vez. Para un trabajo rutinario con n = 10,000 observaciones, B = 2,000 réplicas de bootstrap y almacenamiento float64, eso suponía un tensor de 160 MB solo para calcular un número resumen por réplica. La fuente argumenta que esto convirtió la carga de trabajo en un problema de tráfico de memoria, no de cómputo: los datos se escribían en DRAM y luego se leían de nuevo una vez para la reducción, mientras que la salida útil era solo 16 kB.

En trabajos más grandes, la brecha de memoria se ampliaba aún más. Con B = 50,000 sobre una serie de n = 2,000, la ruta que materializaba alcanzó un pico de 1.94 GB, frente a 20 MB para la ruta en streaming —alrededor de 97x menos memoria—, medido el 2026-07-04 en v0.4.0. Para la forma del ejemplo trabajado en un remuestreo por bloques estacionarios, medida el 2026-07-11, la memoria residente máxima fue de 617 MB para la materialización frente a 234 MB para el streaming, describiéndose 234 MB como la línea base mínima del proceso.

Recomendado

SQLite manejó 315 millones de solicitudes diarias en un portátil

La solución fue reemplazar pasos separados de construcción de arrays por un único kernel compilado que maneja cada réplica en una sola pasada: construir índices, recoger valores, aplicar el reductor y emitir solo la estadística. El tensor completo de réplicas nunca existe en esta ruta rápida. La implementación también usa índices de remuestreo int32 en lugar de int64, con un error explícito si un índice excede el rango de 32 bits, y permite que el tensor de simulación devuelto se almacene como float32 mientras el ajuste del modelo y las reducciones permanecen en float64.

El artículo vincula este diseño a un principio de sistemas más amplio: mantener el conjunto de trabajo en memoria rápida y evitar escribir grandes intermedios. Trae una comparación directa con FlashAttention, que el autor cita por evitar la materialización de la gran matriz de atención N × N y ofrecer una mejora de 7.6x en la atención de GPT-2. Las limitaciones de hardware difieren, pero el principio es el mismo.

Queda una salvedad: el tensor completo de réplicas sigue estando disponible cuando los usuarios lo desean, y en esa ruta de materialización el backend predeterminado de tsbootstrap sigue siendo más lento que el del competidor. Pero en la ruta principal que más importa para cargas de trabajo centradas en reducciones, el rediseño cambió la economía de contar FLOPs a contar bytes —y los bytes fueron el cuello de botella desde el principio.