Auteurs:  (1) Iason Ofeidis, Département de génie électrique et Yale Institute for Network Science, Yale University, New Haven {Contribution égale} ;  (2) Diego Kiedanski, Département de génie électrique et Yale Institute for Network Science, Yale University, New Haven {Contribution égale} ;  (3) Leandros TassiulasLevon Ghukasyan, Activeloop, Mountain View, Californie, États-Unis, Département de génie électrique et Yale Institute for Network Science, Yale University, New Haven.  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.  Cet article est   sous licence CC 4.0. disponible sur arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Read My Stories

We cover the most cutting edge academic research and expert blog posts on serialization. Also big fans of the Serial pod

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

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Nomades numériques, écoutez : ce que vous devez savoir sur le nouveau visa DTV de la Thaïlande

Valhalla de Floki se joint en tant que sponsor associé de la tournée indienne au Sri Lanka

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Nomades numériques, écoutez : ce que vous devez savoir sur le nouveau visa DTV de la Thaïlande

Valhalla de Floki se joint en tant que sponsor associé de la tournée indienne au Sri Lanka

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps