🤖 machine learning

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

Cet article démontre que les microbenchmarks de décodeur JPEG monothread échouent à prédire les performances réelles des DataLoader ML sur diverses architectures CPU, révélant que les configurations de workers multithread et les comportements spécifiques des décodeurs inversent souvent les classements de débit et soulignant que torchvision et simplejpeg constituent les choix les plus robustes pour les charges de travail PyTorch.

Auteurs originaux : Vladimir Iglovikov

Publié 2026-05-12

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Vladimir Iglovikov

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous gérez une cuisine de restaurant très fréquentée. Votre objectif est de faire parvenir des plats délicieux (les données) depuis le garde-manger (le stockage) aux chefs (le modèle d'IA) aussi rapidement que possible. Le « décodeur JPEG » est le sous-chef dont la seule tâche consiste à déballer les emballages alimentaires (décompresser les images JPEG) afin que le chef principal puisse cuisiner.

Pendant des années, les gens ont tenté de trouver le meilleur sous-chef en réalisant un test simple : À quelle vitesse une personne peut-elle déballer un seul colis ? Ils chronomètraient une seule personne, sélectionnaient la plus rapide et l'embauchaient pour toute la cuisine.

Ce papier soutient que ce test simple est trompeur. Le fait que quelqu'un soit le plus rapide pour déballer un seul colis dans une pièce calme ne signifie pas qu'il est le meilleur choix pour une cuisine chaotique et bondée où plusieurs membres du personnel travaillent ensemble.

Voici la décomposition des conclusions du papier en utilisant des analogies du quotidien :

1. Le « Sprint en Solitaire » contre le « Relais d'Équipe »

Le papier a testé 12 différents « outils de déballage » (bibliothèques logicielles comme simplejpeg, torchvision, OpenCV, etc.) sur cinq types différents de processeurs informatiques (comme les puces Intel, AMD et ARM).

L'Ancienne Méthode (Sprint en Solitaire) : Ils ont chronométré la vitesse à laquelle chaque outil pouvait décoder une image seul.
- Résultat : Certains outils, comme simplejpeg, étaient les gagnants clairs.
La Nouvelle Méthode (Relais d'Équipe) : Ils ont simulé un environnement d'entraînement réel où un « DataLoader » (le manager de la cuisine) envoie des images à plusieurs travailleurs (processus) simultanément.
- Résultat : Le classement a complètement changé !
- La Surprise : Sur certains ordinateurs, un outil arrivé 9e dans le sprint en solitaire (comme imageio) a bondi vers le premier échelon lorsqu'il travaillait en équipe. Sur d'autres, le gagnant en solitaire s'est retrouvé en retrait.

L'Analogie : Imaginez un coureur qui est le meilleur sprinter au monde (Gagnant en Solitaire). Mais lorsque vous le placez dans une course de relais où il doit passer un témoin à trois autres personnes, il peut être terrible pour ce passage. Le papier dit : Ne engagez pas le meilleur sprinter si vous avez besoin d'une équipe de relais ; engagez le meilleur joueur d'équipe.

2. La « Personnalité du Matériel » Compte

Le papier a découvert que l'outil « meilleur » dépend entièrement du type de processeur informatique que vous utilisez. Il n'y a pas de réponse universelle.

Le Fossé des Générations AMD : Ils ont testé deux générations de processeurs AMD (Zen 4 et Zen 5).
- Sur Zen 4, ajouter plus de travailleurs aidait jusqu'à 4 personnes, mais ajouter une 8e personne ralentissait en fait les choses (comme ajouter trop de cuisiniers dans une petite cuisine).
- Sur Zen 5, ajouter plus de travailleurs continuait d'aider jusqu'à 8 personnes.
- Leçon : Ce qui fonctionne pour une génération de matériel peut être un désastre pour la suivante.

3. Le Problème du « Colis Abîmé » (Robustesse)

Dans une vraie cuisine, parfois un colis est déchiré ou mal étiqueté. Un bon sous-chef doit le gérer avec élégance.

Certains outils étaient « stricts » : S'ils voyaient une image bizarre, ils s'arrêtaient et la sautaient.
Certains outils étaient « robustes » : Ils géraient l'image bizarre et continuaient.
La Découverte : Certains des outils « stricts » les plus rapides ont sauté une image spécifique dans l'ensemble de test. Si vous entraînez une IA, sauter des données peut être néfaste. Le papier a découvert que des outils comme torchvision et simplejpeg étaient les gagnants « robustes » — ils étaient rapides et ne sautaient aucune image.

4. La « Pénalité ARM »

Ils ont testé un outil populaire appelé TensorFlow.

Sur les ordinateurs Intel et AMD, il était rapide.
Sur les ordinateurs ARM (souvent utilisés dans les appareils mobiles et les nouveaux serveurs), il était considérablement plus lent — environ 40 % plus lent que la meilleure option.
Leçon : Si vous utilisez un ordinateur ARM, ne supposez pas que TensorFlow est votre meilleur choix pour le chargement d'images.

Le Verdict Final : Comment Choisir ?

Le papier conclut que vous ne pouvez pas choisir un outil simplement en regardant un classement du « thread unique le plus rapide ». Au lieu de cela, vous devez considérer l'ensemble de la situation :

Si vous voulez la meilleure vitesse moyenne : Utilisez torchvision. C'était le meilleur performant le plus constant dans l'ensemble.
Si vous voulez la vitesse « pire cas » la plus sûre : Utilisez simplejpeg. C'était le plus fiable, jamais le plus lent, et il ne sautait jamais une image.
Si vous avez besoin d'une sauvegarde fiable : Utilisez OpenCV. Il n'était pas toujours le numéro 1, mais il était toujours dans le top 10 % (au-dessus de 90 % du gagnant) sur chaque ordinateur testé.

La Grande Conclusion :
Arrêtez de juger une bibliothèque en fonction de sa rapidité dans le vide. Pour construire un bon pipeline d'entraînement d'IA, vous devez tester comment l'outil se comporte lorsqu'il travaille réellement en équipe, sur votre type spécifique d'ordinateur, et en gérant des données réelles désordonnées. L'outil « le plus rapide » dans une course en solitaire pourrait être le mauvais choix pour votre équipe.

Résumé technique : Les benchmarks de décodeurs JPEG mono-thread évaluent incorrectement les chargeurs de données ML

Énoncé du problème
Dans l'infrastructure d'apprentissage automatique, le chargement d'images devient souvent le goulot d'étranglement qui limite le débit d'entraînement, entraînant une inactivité des GPU. La réponse standard de l'industrie consiste à évaluer les décodeurs JPEG à l'aide de microbenchmarks mono-processus et mono-thread pour identifier le décodeur le plus rapide (images/seconde). Cet article soutient que cette conception d'évaluation encode une affirmation fausse : à savoir que le débit d'un décodeur mono-thread identifie avec précision le décodeur optimal pour les chargeurs de données d'entraînement. En réalité, les pipelines d'entraînement opèrent dans des environnements complexes impliquant des workers DataLoader multi-processus, des effets aux limites Python/C, des pools de threads de bibliothèques et des comportements spécifiques de planification CPU. Un benchmark isolant un seul appel de décodeur ne parvient pas à capturer ces conditions, ce qui peut conduire à des choix de bibliothèques sous-optimaux ou à négliger des politiques de robustesse critiques pour la stabilité opérationnelle.

Méthodologie
Les auteurs examinent l'hypothèse d'évaluation en comparant un protocole mono-thread courant à un protocole conscient du DataLoader dans un environnement contrôlé et apparié.

Charge de travail : La division complète de validation ImageNet (50 000 fichiers JPEG) est décodée entièrement depuis la mémoire pour isoler la surcharge de décodage et de chargement de la latence disque ou réseau.
Décodeurs : Douze chemins de décodage accessibles en Python ont été évalués : simplejpeg, turbojpeg, jpeg4py, kornia-rs, opencv, imagecodecs, pyvips, pillow, skimage, imageio, torchvision et tensorflow.
Matériel : Cinq instances Google Cloud à 16 vCPU appariées représentant différents fournisseurs, jeux d'instructions (ISA) et générations : Intel Emerald Rapids, AMD Zen 4, AMD Zen 5, ARM Neoverse V2 (Google Axion) et ARM Neoverse N1 (Ampere Altra).
Protocoles :
1. Mono-thread : Débit de décodage basé sur la mémoire.
2. PyTorch DataLoader : Débit mesuré pour des nombres de workers $\{0, 2, 4, 8\}$ .
3. Robustesse : Prise en compte des images sautées (échecs) lors du décodage.
Politique statistique : L'étude utilise des échantillons de débit bruts par exécution stockés en JSON plutôt que de se fier uniquement aux moyennes des tableaux. Des seuils de signification pratique sont appliqués (1 % pour le mono-thread, 5 % pour le débit DataLoader) pour distinguer les gagnants statistiquement isolés des meilleurs performers de premier rang.

Contributions clés

Comparaison de protocoles : Une comparaison directe des classements des décodeurs mono-thread par rapport aux classements de débit DataLoader sur la même charge de travail, les mêmes bibliothèques et des environnements fixés.
Artéfact reproductible : Publication d'une CLI installable et de scripts d'exécution Google Cloud pour reproduire le benchmark localement ou dans le cloud, incluant les données JSON brutes et les figures générées.
Isolement des variables : Identification des changements de rang et des effets de mise à l'échelle des workers qui sont invisibles lorsque l'évaluation est restreinte à une seule famille de CPU ou à un seul nombre de workers.
Protocole de décision opérationnelle : Un cadre convertissant les résultats des benchmarks en recommandations opérationnelles tenant compte du choix du décodeur, du nombre de workers, de la microarchitecture et des politiques de robustesse.

Résultats clés

Inversion de rang : Les leaders mono-thread échouent fréquemment à être des leaders DataLoader. Sur trois des cinq plateformes, le leader mono-thread n'est pas le leader DataLoader de pointe.
- Neoverse V2 : imageio se classe 9e en mono-thread mais se classe dans le premier rang en DataLoader (aux côtés de torchvision).
- AMD Zen 4 : torchvision passe de la 7e place en mono-thread au premier rang DataLoader.
- Neoverse N1 : imagecodecs mène en mono-thread mais se classe 4e en débit DataLoader de pointe.
Mise à l'échelle du nombre de workers : Le nombre optimal de workers n'est pas universel. Sur AMD Zen 4, la plupart des décodeurs atteignent leur pic à 4 workers, tandis que sur Zen 5 et les plateformes ARM, les performances continuent généralement de s'améliorer jusqu'à 8 workers.
Échecs de robustesse : Les décodeurs stricts (jpeg4py, kornia-rs, turbojpeg) sautent systématiquement le même rare JPEG ImageNet (index 19876) sur toutes les plateformes, réduisant leur débit effectif. TensorFlow présente une pénalité de performance significative sur les architectures ARM (chutant à ~59 % du gagnant local) par rapport à x86.
Recommandations de premier rang :
- Niveau Zéro-Saut : Seuls torchvision, simplejpeg et OpenCV ont obtenu zéro saut observé et sont restés au-dessus de 90 % du gagnant local de la plateforme sur tous les CPU testés.
- Nuance de performance : torchvision offre le débit normalisé moyen le plus élevé, tandis que simplejpeg fournit le débit minimum le plus élevé sur les plateformes. OpenCV sert de solution de repli robuste polyvalente, atteignant systématiquement 91,1 % à 97,4 % du gagnant local.

Signification et affirmations
La signification principale de l'article est méthodologique : il démontre que le protocole d'évaluation doit correspondre à l'affirmation de déploiement.

Portée de l'affirmation : Les auteurs ne revendiquent pas un décodeur « le plus rapide » universel, ni ne prétendent que ARM est intrinsèquement lent ou qu'AMD s'étend mal. Ils affirment plutôt que, sous un harnais PyTorch DataLoader basé sur fork, les classements des décodeurs dépendent du contexte.
Impact opérationnel : Pour les charges de travail PyTorch DataLoader, s'appuyer sur des benchmarks mono-thread peut conduire à sélectionner un décodeur qui est 4,7 % à 7,4 % plus lent que le choix optimal pour cette plateforme spécifique.
Conclusion : Un benchmark valide pour les pipelines d'entraînement doit rapporter simultanément le débit à l'échelle du chargeur, la microarchitecture cible et le comportement d'échec de décodage. L'article fournit un cadre pour rendre ces limites explicites, passant des métriques de classement unique vers des recommandations en niveaux, conscientes du contexte.