Hilo por núcleo (Thread-per-core)

• Este artículo analiza el debate en la comunidad de Rust sobre el uso de ejecutores multihilo, es decir, runtimes async que realizan work-stealing para distribuir equilibradamente las tareas.
• Algunos usuarios de Rust defienden una arquitectura alternativa llamada "thread-per-core", que promete mejor rendimiento y una implementación más sencilla.
• El término "thread-per-core" es engañoso. Todos los ejecutores multihilo son thread-per-core: crean un hilo del sistema operativo por núcleo y programan tareas sobre esos hilos.
• Thread-per-core combina tres ideas: manejar la concurrencia en espacio de usuario, hacer que la E/S sea asíncrona para evitar bloquear hilos, y particionar los datos entre núcleos de CPU para eliminar el costo de sincronización y el movimiento de datos entre cachés de CPU.
• La controversia gira principalmente en torno al tercer punto, y con async Rust se pueden cumplir los dos primeros requisitos.
• En una arquitectura thread-per-core se pueden aplicar dos optimizaciones: robar trabajo entre hilos y compartir la menor cantidad de estado posible.
• El work-stealing mejora la tail latency al permitir que todos los hilos tengan siempre trabajo, pero es difícil de implementar y puede provocar costos de sincronización y fallos de caché.
• El enfoque share-nothing mejora la tail latency al mantener los datos en la caché más rápida asociada a un solo núcleo de CPU, pero puede ser difícil de implementar en aplicaciones complejas que necesitan modificar estado en múltiples particiones.
• El artículo sugiere que, en sistemas con estado compartido, el work-stealing podría mejorar el uso de CPU bajo carga.

[GN⁺]

Opinión de Hacker News

• El punto central del debate no es el robo de trabajo de los ejecutores de un hilo por núcleo, sino si async/await en Rust es una buena abstracción.
• El modelo de un hilo por núcleo se inventó para resolver la escalabilidad y eficiencia del cómputo en servidores comunes con muchos núcleos, y se ha demostrado que es excelente para trabajos de I/O bound de alto rendimiento.
• La arquitectura de un hilo por núcleo llegó para quedarse por su escalabilidad y eficiencia, pero la mayoría de los ingenieros de software tienen una intuición limitada sobre cómo es un diseño moderno e idiomático de un hilo por núcleo.
• Algunas aplicaciones se adaptan mejor a sistemas de un solo hilo, y Rust permite esa flexibilidad.
• Hay críticas a la programación async de Rust, incluyendo que exige Send + Sync + 'static, algo que a algunos les resulta pesado.
• El bound Send es un requisito que permite mover tareas entre hilos del ejecutor, y parece ser una deficiencia del sistema async de Rust.
• No existe un enfoque único que logre el mejor rendimiento para todos los programas, y usar async se considera una optimización prematura para muchos programas en Rust.
• Como los cambios de contexto del kernel son costosos, se prefiere un diseño de un hilo por núcleo, aunque la planificación con cambios de contexto en espacio de usuario también puede causar problemas.
• El robo de trabajo es una forma de resolver la latencia de cola, pero provoca fallos de caché y restricciones adicionales para los desarrolladores, como Send, Sync y 'static.