Un aperçu du paysage des chargeurs de données : discussion

Tableau des liens

• Résumé et introduction
• Chargeurs de données
• Montage expérimental
• Résultats numériques
• Discussion
• Travaux connexes
• Conclusion, remerciements et références
• A. Résultats numériques (suite)

5. DISCUSSION

Dans ce travail, nous avons utilisé le temps comme outil principal pour comparer les performances des différentes bibliothèques. Il y a plusieurs choses à dire à ce sujet. Tout d’abord, nous avons remarqué que les temps d’exécution sont assez variables et dépendent de processus en arrière-plan difficiles à contrôler. Dans le même temps, l’accès aux ressources multi-GPU est coûteux, ce qui limite le nombre d’expériences pouvant être réalisées. Idéalement, nous aurions effectué plus de trois répétitions de chaque expérience avec plus de paramètres (plus de travailleurs, plus de tailles de lots), mais nous n'avions pas les ressources nécessaires pour cela. Puisque nous créons tout notre code open source, nous invitons les lecteurs à exécuter les tests sur leur propre matériel et à rapporter les résultats. Dans le même temps, les bibliothèques sont mises à jour assez souvent et un changement de version peut augmenter ou diminuer considérablement ses performances.

À la lumière des points ci-dessus, nous encourageons le lecteur à internaliser les aspects qualitatifs de cet article, mais attention, les chiffres obtenus ici sont susceptibles de changer.

Deuxièmement, un aspect plus difficile à comparer est la facilité d’utilisation des bibliothèques considérées dans ce projet. La plupart des bibliothèques incluses dans ce benchmark ne disposent pas d'une documentation complète et s'appuient principalement sur des exemples concrets. Par conséquent, la mise en œuvre dans ces bibliothèques n’est pas triviale et sujette à des inefficacités. L'un des avantages de rendre notre code open source est que nous permettons à tout développeur d'identifier et d'améliorer notre code. Ceci est particulièrement pertinent car nous espérons que les références créées dans ce projet pourront être utilisées comme code passe-partout pour la communauté.

On constate qu’il ne semble pas y avoir de meilleure bibliothèque que toutes les autres. Au lieu de cela, chacun a ses propres atouts. Prenons l'exemple de FFCV : il semble être le plus rapide de nos expérimentations, mais le manque de support pour les transformations d'étiquettes l'empêche d'être adopté dans des projets nécessitant de telles fonctionnalités.

Nous espérons analyser l'interaction entre le filtrage et la formation sur plusieurs GPU dans de futurs travaux. Dans le même temps, il serait intéressant d’explorer les capacités d’évolutivité de ces bibliothèques à mesure que le nombre de GPU augmente. De même, il serait très intéressant de comparer les bibliothèques de chargement de données en termes de performances lors de l'étape de brassage dans le flux de travail de formation DL, car cela peut avoir un impact significatif sur le temps total de formation, et sa mise en œuvre est un problème non trivial. où il existe plusieurs types d’approches.

La recherche sur les bibliothèques permettant le chargement de données à partir d'un stockage distant et montrant des résultats comparables à ceux des expériences de stockage local nous a incité à explorer l'idée de formuler et de concevoir une politique de mise en cache pour le streaming de données sur un réseau. Dans ce contexte, la réduction du temps de transfert d'un point de données (par exemple, une image) peut réduire considérablement la durée globale de la formation (et éventuellement les coûts si l'utilisation du réseau est payante). L'idée de mettre en cache un ensemble de données réseau pendant la formation n'est pas nouvelle (Mohan et al., 2020). Pourtant, on suppose souvent que l’ensemble des données peut être mis en cache lorsqu’on parle de formation et de diffusion de données. De plus, on suppose que tous les échantillons seront utilisés une fois par époque (Kumar & Sivathanu, 2020), comme c'est traditionnellement le cas. Nous souhaitons explorer ce qui se passe lorsque la taille du cache est petite, et également supprimer l'obligation d'utiliser chaque point de données une fois par époque. Une telle formulation devrait s’inspirer de l’apprentissage actif, de la synthèse des données et de l’apprentissage curriculaire.