Un aperçu du paysage des chargeurs de données : résultats numériques

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)

4. RÉSULTATS NUMÉRIQUES

Pour la première série d'expériences, nous avons évalué les performances de toutes les bibliothèques lors de la modification du nombre de travailleurs (voir 2) ainsi que de la taille du lot. Ces expériences ont été exécutées sur un serveur local avec les spécifications suivantes : Intel(R) Core(TM) i9-10900K, 2 x NVIDIA GeForce RTX 3090 et un disque dur avec 10 To de stockage (6 Go/s) [5].

Nous avons évalué les trois modes : par défaut (un seul GPU), distribué (deux GPU) et filtrage (un seul GPU) pour toutes les combinaisons possibles de 0, 1 et 2 workers. Pour CIFAR10 et RANDOM, la taille du lot était de 16, 64 ou 128. Pour CoCo, nous avons utilisé des valeurs plus petites : 1, 2 et 4. Toutes ces expériences ont utilisé un seuil de 10 et la variante qui exécute le modèle (forward & passe arrière).

4.1 Vitesse en fonction de la taille des lots et des travailleurs

La première chose que nous remarquons en examinant les expériences est que la variance entre les bibliothèques dépend du problème et de l'ensemble de données utilisé. La figure 4 montre une telle comparaison pour CIFAR10 sur un seul GPU, tandis que la figure 5 montre le même résultat pour CoCo, également sur un seul GPU.

Il fallait s'y attendre étant donné que dans ce dernier cas, le temps nécessaire pour calculer les passes avant et arrière domine le temps d'exécution global, ce qui n'est pas le cas pour l'image.

classification. Vous remarquerez également la différence globale de vitesse : de 4 000 échantillons par seconde à seulement 20.

Deuxièmement, nous soulignons que l’augmentation de la taille du lot augmente la vitesse de traitement dans presque tous les cas. Toutefois, ce n’est pas le cas du nombre de travailleurs. Nous pouvons observer sur la figure 6 que les performances de FFCV se dégradent à mesure que le nombre de nœuds de calcul augmente, tandis que Deep Lake se stabilise à 1 nœud de calcul et non à 2. Une explication est que les bibliothèques ont leurs propres algorithmes internes qui décident comment répartir les threads et les processus selon les besoins. Le point ci-dessus est pertinent pour les utilisateurs de ces bibliothèques, car l’expérience avec l’une d’entre elles pourrait ne pas se traduire par une autre.

4.2 Gains de vitesse lors de l'utilisation de DDP

Une caractéristique souhaitable d’un chargeur de données est sa capacité à évoluer de manière linéaire avec le nombre de GPU. Cela n'est pas toujours possible et dépend du mécanisme de chargement interne de chaque bibliothèque. Nous explorons les performances de ces bibliothèques en comparant l'augmentation de la vitesse lors de l'utilisation d'un ou deux GPU. La figure 7 montre les résultats pour l'ensemble de données RANDOM. Chaque barre représente la vitesse maximale atteinte pour toutes les tailles de lots, nombre de travailleurs et répétitions. D'une certaine manière, cela reflète la vitesse maximale atteignable par la bibliothèque. Nous observons que les bibliothèques accélèrent d'environ 40 %, soit moins de la moitié d'une augmentation linéaire en moyenne. Deux cas sont particulièrement surprenants. D'une part, Torchdata fonctionne moins bien avec deux GPU qu'avec un seul. D’un autre côté, la FFCV a obtenu une augmentation de vitesse supérieure à ce qui était théoriquement possible. Plusieurs artefacts peuvent être en jeu ici, mais cela est très probablement dû au nombre limité de répétitions que nous avons pu exécuter (en raison de ressources limitées). Cela pourrait également

indiquer une mauvaise configuration dans Torchdata : la documentation sur l'exécution d'expériences dans des environnements multi-GPU est limitée pour la plupart des bibliothèques.

4.3 Comparaison entre avec et sans passe avant et arrière

Comme nous en avons discuté lors de la présentation de l'algorithme 1, nous avons dû décider si nous allions intégrer les passes avant et arrière dans le calcul de la vitesse. Il y a des arguments pour les deux. D'une part, l'inclusion des passes avant et arrière reflète mieux le temps d'entraînement réel de l'algorithme. Dans le même temps, certaines bibliothèques peuvent optimiser de manière préventive les étapes normalement effectuées lors de la passe avant.

s’arrêter là semblerait prendre plus de temps qu’ils ne le font.

D'un autre côté, si le temps nécessaire aux passages avant et arrière est beaucoup plus long que le temps nécessaire au seul chargement des données, inclure ce temps dans le calcul masquerait inévitablement la différence entre les bibliothèques.

Pour comprendre si le changement de comportement était perceptible, nous avons utilisé l'ensemble de données RANDOM pour comparer la différence de vitesse moyenne en incluant ou non les deux opérations du modèle dans le calcul. Les résultats sont présentés dans la figure 8. Nous pouvons observer que la plupart des bibliothèques ont une vitesse légèrement accrue lors de l'exclusion du modèle (à l'exception de FFCV, dont les performances chutent de moitié), et surtout, les performances relatives entre les bibliothèques restent presque les mêmes.

4.4 Compromis de vitesse lors du filtrage des données

Pour nos expériences de filtrage, nous avons sélectionné deux classes à conserver pour CIFAR10 et RANDOM : chien et camion, et 0 et 13, respectivement. Pour CoCO, nous avons sélectionné trois classes : pizza, canapé, chat.

Nous avons observé que la plupart des bibliothèques ne disposent pas d'un bon mécanisme de filtrage qui évite d'itérer sur l'ensemble de l'ensemble de données. Par exemple, notre implémentation de filtrage PyTorch nécessite la création d'un échantillonneur personnalisé avec les indices des images souhaitées.

C'est assez rapide pour un petit ensemble de données mais devient irréalisable pour de grands ensembles de données : filtrer CoCo à l'aide de PyTorch était d'un coût prohibitif. En général, les performances étaient assez similaires avec et sans filtrage[6]. De la même manière que la figure

7, sur la Figure 9, nous pouvons voir le ralentissement dû au filtrage : même s'il était considérable pour Torchdata et Webdataset, nous avons constaté une inversion des résultats lorsque nous travaillons avec le CoCo Dataset.

4.5 Entraînement en streaming sur le réseau

Idéalement, nous pourrions dissocier le stockage des ensembles de données du processus de formation en apprentissage automatique et simplement connecter la base de données stockant nos données au framework ML de notre choix, quel que soit l'emplacement des deux. Cela implique d'envoyer les données d'entraînement sur un réseau et de perdre une vitesse considérable. Compte tenu des coûts élevés liés à la location de matériel accéléré par GPU sur le cloud, il peut sembler que la commodité n'en vaut pas la peine. Mais n'est-ce pas ?

Certaines des bibliothèques considérées dans cet article permettent de spécifier un ensemble de données accessible via Internet : Webdataset, Hub et Deep Lake sont particulièrement performants dans ce domaine[7]. La question devient alors : quelle est l’ampleur du compromis entre facilité d’utilisation et durée d’exécution ?

Nous avons mis en place l’expérience suivante pour offrir un aperçu de cette question. Nous avons exécuté deux époques complètes de l'ensemble de données RANDOM pour les trois bibliothèques : Hub, Deep Lake et Webdataset, tout en modifiant l'origine des données. Trois emplacements ont été considérés : une copie locale dans la machine exécutant le disque dur des expériences, une copie dans un compartiment S3 (dans la région la plus proche de notre machine) et une copie stockée dans MinIO (un équivalent open source de S3 qui peut être hébergé localement) fonctionnant sur une machine similaire au sein du même réseau local (les deux machines étaient connectées via WiFi). L'ordinateur des expériences était équipé d'un processeur Intel(R) Core(TM) i7-7700 à 3,60 GHz, 16 Go de RAM, NVIDIA GeForce RTX

2070 Rev et un disque dur Samsung SSD 850 avec 256 Go de stockage. Concernant la latence, le temps d'aller-retour depuis le poste de travail exécutant les expériences jusqu'au serveur MinIO (situé dans la même pièce et dans le même WiFi local) a pris 59,2 ± 58,5 ms (min. 8,8 ms), tandis que vers le compartiment S3 dans AWS les serveurs ont pris 17,3 ± 1,3 ms (min. 14,8 ms).

La figure 10 représente les durées totales d'exécution pour les neuf expériences, et les pourcentages blancs indiquent le ralentissement (augmentation de la durée d'exécution) par rapport au cas local. Nous pouvons observer que même si pour Hub et Webdataset il y a une augmentation significative lors du passage à AWS, Deep Lake a réussi à maintenir presque la même vitesse avec une augmentation de seulement 13 %. Un autre aperçu utile pourrait être extrait du résultat : le paramètre MinIO montre un ralentissement presque deux fois plus important que le paramètre AWS, comme le montre la figure 10. Ce résultat pourrait s'expliquer principalement par la différence des temps d'aller-retour moyens indiqués ci-dessus, soulignant que Les réseaux locaux (par exemple, les réseaux internes d'entreprise[8]) ne constituent peut-être pas le moyen le plus efficace d'héberger des ensembles de données en raison de leurs configurations et restrictions complexes. En outre, ce résultat indique également que le stockage servant les ensembles de données sur le réseau joue un rôle crucial pour permettre la formation à distance et pourrait soulever des questions sur les meilleures pratiques pour servir les ensembles de données. À savoir, les données de S3 sont servies en parallèle à partir de différents serveurs avec équilibrage de charge alors que nous avions accès à une seule instance MinIO.

Les tracés de toutes les expériences supplémentaires se trouvent à l’annexe A.

[5] https://www.seagate.com/www-content/productcontent/barracuda-fam/barracuda-new/enus/docs/100835983b.pdf

[6] en vitesse. La construction de l'échantillonneur pour PyTorch se fait à l'avance, ce qui affecte considérablement la durée totale d'exécution.

[7] Squirrel a cette capacité, mais nous n'avons pas réussi à spécifier une adresse MinIO, nous l'avons donc exclu de la comparaison. Nous avons eu un problème similaire avec Torchdata.

[8] En l’occurrence un réseau universitaire