Single-Thread JPEG Decoder Benchmarks Mis-Evaluate ML Data Loaders

Resumen Técnico: Los Benchmarks de Decodificadores JPEG de Un Solo Hilo Evalúan Incorrectamente los Cargadores de Datos de ML

Enunciado del Problema
En la infraestructura de aprendizaje automático, la carga de imágenes a menudo se convierte en el cuello de botella que limita el rendimiento del entrenamiento, causando inactividad de la GPU. La respuesta estándar de la industria es evaluar los decodificadores JPEG utilizando microbenchmarks de un solo proceso y un solo hilo para identificar el decodificador más rápido (imágenes/segundo). Este artículo argumenta que este diseño de evaluación codifica una afirmación falsa: que el rendimiento de un decodificador de un solo hilo identifica con precisión el decodificador óptimo para los cargadores de datos de entrenamiento. En realidad, las pipelines de entrenamiento operan dentro de entornos complejos que involucran trabajadores de DataLoader de múltiples procesos, efectos en los límites Python/C, pools de hilos de bibliotecas y comportamientos específicos de planificación de la CPU. Un benchmark que aísla una sola llamada al decodificador falla en capturar estas condiciones, lo que podría llevar a elecciones de bibliotecas subóptimas o a pasar por alto políticas de robustez críticas para la estabilidad operativa.

Metodología
Los autores auditan la suposición de evaluación comparando un protocolo común de un solo hilo contra un protocolo consciente de DataLoader en un entorno controlado y emparejado.

• Carga de trabajo: La partición completa de validación de ImageNet (50.000 archivos JPEG) se decodifica completamente desde la memoria para aislar la sobrecarga de decodificación y carga de la latencia del disco o de la red.
• Decodificadores: Se evaluaron doce rutas de decodificación accesibles desde Python: simplejpeg, turbojpeg, jpeg4py, kornia-rs, opencv, imagecodecs, pyvips, pillow, skimage, imageio, torchvision y tensorflow.
• Hardware: Cinco instancias de Google Cloud de 16 vCPU emparejadas que representan diferentes proveedores, ISAs y generaciones: Intel Emerald Rapids, AMD Zen 4, AMD Zen 5, ARM Neoverse V2 (Google Axion) y ARM Neoverse N1 (Ampere Altra).
• Protocolos:
  1. Un solo hilo: Rendimiento de decodificación basado en memoria.
  2. PyTorch DataLoader: Rendimiento medido con conteos de trabajadores $\{0, 2, 4, 8\}$.
  3. Robustez: Contabilización de imágenes omitidas (fallos) durante la decodificación.
• Política estadística: El estudio utiliza muestras de rendimiento por ejecución en bruto almacenadas en JSON en lugar de depender únicamente de las medias de las tablas. Se aplican umbrales de significancia práctica (1% para un solo hilo, 5% para el rendimiento de DataLoader) para distinguir entre ganadores estadísticamente aislados y los mejores performers empatados del primer nivel.

Contribuciones Clave

1. Comparación de Protocolos: Una comparación directa de las clasificaciones de decodificadores de un solo hilo frente a las clasificaciones de rendimiento de DataLoader en la misma carga de trabajo, bibliotecas y entornos fijados.
2. Artefacto Reproducible: Lanzamiento de una CLI instalable y scripts de ejecución en Google Cloud para replicar el benchmark localmente o en la nube, incluyendo datos JSON en bruto y figuras generadas.
3. Aislamiento de Variables: Identificación de cambios de rango y efectos de escalado de trabajadores que son invisibles cuando la evaluación se restringe a una sola familia de CPU o a un solo conteo de trabajadores.
4. Protocolo de Decisión Operativa: Un marco que convierte los resultados del benchmark en recomendaciones operativas que tienen en cuenta la elección del decodificador, el conteo de trabajadores, la microarquitectura y las políticas de robustez.

Resultados Clave

• Inversión de Rango: Los líderes de un solo hilo a menudo no son líderes de DataLoader. En tres de las cinco plataformas, el líder de un solo hilo no es el líder máximo de DataLoader.
  • Neoverse V2: imageio ocupa el puesto 9 en un solo hilo pero empató en el primer nivel en DataLoader (junto con torchvision).
  • AMD Zen 4: torchvision sube del puesto 7 en un solo hilo al primer nivel de DataLoader.
  • Neoverse N1: imagecodecs lidera en un solo hilo pero ocupa el puesto 4 en el rendimiento máximo de DataLoader.
• Escalado por Conteo de Trabajadores: El conteo óptimo de trabajadores no es universal. En AMD Zen 4, la mayoría de los decodificadores alcanzan su punto máximo con 4 trabajadores, mientras que en Zen 5 y las plataformas ARM, el rendimiento generalmente sigue mejorando hasta 8 trabajadores.
• Fallos de Robustez: Los decodificadores estrictos (jpeg4py, kornia-rs, turbojpeg) omiten consistentemente el mismo JPEG raro de ImageNet (índice 19876) en todas las plataformas, reduciendo su rendimiento efectivo. TensorFlow exhibe una penalización de rendimiento significativa en arquitecturas ARM (descendiendo a ~59% del ganador local) en comparación con x86.
• Recomendaciones del Primer Nivel:
  • Nivel de Cero Omisiones: Solo torchvision, simplejpeg y OpenCV lograron cero omisiones observadas y se mantuvieron por encima del 90% del ganador de la plataforma local en todas las CPUs probadas.
  • Matiz de Rendimiento: torchvision ofrece el mayor rendimiento normalizado medio, mientras que simplejpeg proporciona el rendimiento mínimo más alto entre plataformas. OpenCV sirve como un respaldo general robusto, logrando consistentemente entre el 91,1% y el 97,4% del ganador local.

Significado y Afirmaciones
El significado principal del artículo es metodológico: demuestra que el protocolo de evaluación debe coincidir con la afirmación de implementación.

• Alcance de la Afirmación: Los autores no afirman un decodificador "más rápido" universal, ni afirman que ARM sea inherentemente lento o que AMD escale mal. En cambio, afirman que bajo un arnés de DataLoader de PyTorch basado en fork, las clasificaciones de decodificadores dependen del contexto.
• Impacto Operativo: Para cargas de trabajo de DataLoader de PyTorch, confiar en benchmarks de un solo hilo puede llevar a seleccionar un decodificador que es un 4,7% a un 7,4% más lento que la elección óptima para esa plataforma específica.
• Conclusión: Un benchmark válido para pipelines de entrenamiento debe reportar simultáneamente el rendimiento a escala de cargador, la microarquitectura objetivo y el comportamiento de fallos de decodificación. El artículo proporciona un marco para hacer explícitos estos límites, alejándose de las métricas de una sola tabla de clasificación hacia recomendaciones por niveles y conscientes del contexto.