Autoren:  (1) Iason Ofeidis, Department of Electrical Engineering und Yale Institute for Network Science, Yale University, New Haven {Gleicher Beitrag};  (2) Diego Kiedanski, Department of Electrical Engineering und Yale Institute for Network Science, Yale University, New Haven {Gleicher Beitrag};  (3) Leandros TassiulasLevon Ghukasyan, Activeloop, Mountain View, CA, USA, Fakultät für Elektrotechnik und Yale Institute for Network Science, Yale University, New Haven.  Linktabelle   Zusammenfassung und Einleitung   Datenlader   Versuchsaufbau   Numerische Ergebnisse   Diskussion   Ähnliche Projekte   Schlussfolgerung, Danksagungen und Referenzen   A. Numerische Ergebnisse, Fortsetzung  4. NUMERISCHE ERGEBNISSE  Für die erste Reihe von Experimenten haben wir die Leistung aller Bibliotheken beim Ändern der Anzahl der Worker (siehe 2) sowie der Batchgröße bewertet. Diese Experimente wurden auf einem lokalen Server mit den folgenden Spezifikationen ausgeführt: Intel(R) Core(TM) i9-10900K, 2 x NVIDIA GeForce RTX 3090 und eine Festplatte mit 10 TB Speicher (6 GB/s) [5].  Wir haben die drei Modi Standard (einzelne GPU), verteilt (zwei GPUs) und Filterung (einzelne GPU) für alle möglichen Kombinationen von 0, 1 und 2 Workern ausgewertet. Für CIFAR10 und RANDOM betrug die Batchgröße entweder 16, 64 oder 128. Für CoCo haben wir kleinere Werte verwendet: 1, 2 und 4. Bei all diesen Experimenten wurde ein Cutoff von 10 und die Variante verwendet, die das Modell ausführt (Vorwärts- und Rückwärtsdurchlauf).  4.1 Geschwindigkeit in Abhängigkeit von Chargengröße und Arbeitern  Das Erste, was uns bei der Untersuchung der Experimente auffällt, ist, dass die Abweichungen zwischen den Bibliotheken vom Problem und dem verwendeten Datensatz abhängen. Abbildung 4 zeigt einen solchen Vergleich für CIFAR10 auf einer einzelnen GPU, während Abbildung 5 dasselbe Ergebnis für CoCo, ebenfalls auf einer einzelnen GPU, zeigt.  Dies war zu erwarten, da bei letzterem die Zeit, die für die Berechnung des Vorwärts- und Rückwärtsdurchlaufs benötigt wird, die Gesamtlaufzeit dominiert, was bei Bild-   Klassifizierung. Sie werden auch den allgemeinen Geschwindigkeitsunterschied bemerken: von 4000 Samples pro Sekunde auf nur 20.  Zweitens weisen wir darauf hin, dass eine Erhöhung der Batchgröße in fast allen Fällen die Verarbeitungsgeschwindigkeit erhöht. Dies gilt jedoch nicht für die Anzahl der Worker. In Abbildung 6 können wir beobachten, dass die FFCV-Leistung mit zunehmender Anzahl der Worker nachlässt, während Deep Lake bei 1 Worker und nicht bei 2 ein Plateau erreicht. Eine Erklärung dafür ist, dass die Bibliotheken ihre eigenen internen Algorithmen haben, die entscheiden, wie Threads und Prozesse nach Bedarf aufgeteilt werden. Der obige Punkt ist für Benutzer dieser Bibliotheken relevant, da die Erfahrungen mit einer von ihnen möglicherweise nicht gut auf eine andere übertragbar sind.  4.2 Geschwindigkeitsgewinne bei Verwendung von DDP  Ein wünschenswertes Merkmal eines Dataloaders ist seine Fähigkeit, linear mit der Anzahl der GPUs zu skalieren. Dies ist nicht immer möglich und hängt vom internen Lademechanismus jeder Bibliothek ab. Wir untersuchen, wie diese Bibliotheken abgeschnitten haben, indem wir die Geschwindigkeitssteigerung bei Verwendung einer oder zwei GPUs vergleichen. Abbildung 7 zeigt die Ergebnisse für den RANDOM-Datensatz. Jeder Balken stellt die maximale Geschwindigkeit dar, die über alle Batchgrößen, Anzahl der Worker und Wiederholungen hinweg erreicht wurde. In gewisser Weise spiegelt dies die maximale Geschwindigkeit wider, die von der Bibliothek erreicht werden kann. Wir beobachten, dass Bibliotheken um etwa 40 % schneller werden, also im Durchschnitt weniger als die Hälfte einer linearen Steigerung. Zwei Fälle sind besonders überraschend. Einerseits schneidet Torchdata mit zwei GPUs schlechter ab als mit einer einzigen. Andererseits erreichte FFCV eine Geschwindigkeitssteigerung, die stärker war als theoretisch möglich. Es gibt mehrere Artefakte, die hier eine Rolle spielen können, aber höchstwahrscheinlich liegt es an der begrenzten Anzahl von Wiederholungen, die wir ausführen konnten (aufgrund begrenzter Ressourcen). Dies könnte auch   weisen auf eine Fehlkonfiguration in Torchdata hin: Die Dokumentation zum Ausführen von Experimenten in Umgebungen mit mehreren GPUs ist für die meisten Bibliotheken begrenzt.   4.3 Vergleich mit und ohne Vorwärts- und Rückwärtsdurchgang  Wie wir bei der Vorstellung von Algorithmus 1 besprochen haben, mussten wir entscheiden, ob wir die Vorwärts- und Rückwärtsdurchläufe in die Geschwindigkeitsberechnung einbeziehen würden. Es gibt Argumente für beides. Einerseits spiegelt die Einbeziehung der Vorwärts- und Rückwärtsdurchläufe die tatsächliche Trainingszeit des Algorithmus besser wider. Gleichzeitig könnten einige Bibliotheken präventiv Schritte optimieren, die normalerweise während des Vorwärtsdurchlaufs ausgeführt werden, sodass   Wenn man dort anhält, scheint es länger zu dauern, als es tatsächlich der Fall ist.  Wenn andererseits die für den Vorwärts- und Rückwärtsdurchlauf benötigte Zeit viel länger ist als die Zeit, die allein zum Laden der Daten benötigt wird, würde das Einbeziehen dieser Zeit in die Berechnung zwangsläufig den Unterschied zwischen den Bibliotheken verbergen.  Um zu verstehen, ob die Verhaltensänderung spürbar war, haben wir den RANDOM-Datensatz verwendet, um den Unterschied in der Durchschnittsgeschwindigkeit zu vergleichen, wenn die beiden Modelloperationen in die Berechnung einbezogen wurden und wenn nicht. Die Ergebnisse sind in Abbildung 8 dargestellt. Wir können beobachten, dass die Geschwindigkeit der meisten Bibliotheken leicht zunimmt, wenn das Modell ausgeschlossen wird (mit Ausnahme von FFCV, dessen Leistung auf die Hälfte sinkt), und, was am wichtigsten ist, die relative Leistung zwischen den Bibliotheken bleibt nahezu gleich.  4.4 Geschwindigkeitskompromisse beim Filtern von Daten  Für unsere Filterexperimente haben wir zwei Klassen für CIFAR10 und RANDOM ausgewählt: Hund und LKW sowie 0 und 13. Für CoCO haben wir drei Klassen ausgewählt: Pizza, Couch, Katze.  Wir haben festgestellt, dass die meisten Bibliotheken keinen guten Filtermechanismus haben, der die Iteration über den gesamten Datensatz vermeidet. Beispielsweise erfordert unsere PyTorch-Filterimplementierung die Erstellung eines benutzerdefinierten Samplers mit den Indizes der gewünschten Bilder.  Dies ist bei kleinen Datensätzen recht schnell, wird aber bei großen Datensätzen undurchführbar: Das Filtern von CoCo mit PyTorch war unerschwinglich teuer. Im Allgemeinen war die Leistung beim Filtern und ohne Filtern recht ähnlich[6]. Ähnlich wie in Abbildung   7. In Abbildung 9 können wir die Verlangsamung als Folge der Filterung sehen: Obwohl sie bei Torchdata und Webdataset beträchtlich war, sahen wir bei der Arbeit mit dem CoCo-Dataset eine Umkehrung der Ergebnisse.  4.5 Training beim Streaming über das Netzwerk  Im Idealfall könnten wir die Datenspeicherung vom Trainingsprozess des maschinellen Lernens entkoppeln und einfach die Datenbank, in der unsere Daten gespeichert sind, mit dem ML-Framework unserer Wahl verbinden, unabhängig davon, wo sich beide befinden. Das bedeutet, dass die Trainingsdaten über ein Netzwerk gesendet werden und ein erheblicher Geschwindigkeitsverlust entsteht. Angesichts der hohen Kosten, die mit der Anmietung von GPU-beschleunigter Hardware in der Cloud verbunden sind, könnte man meinen, dass sich der Komfort nicht lohnt. Aber ist das nicht der Fall?  Einige der in diesem Artikel behandelten Bibliotheken ermöglichen die Angabe eines über das Internet zugänglichen Datensatzes: Webdataset, Hub und Deep Lake sind hierfür besonders gut geeignet[7]. Die Frage ist dann: Wie groß ist der Kompromiss zwischen Benutzerfreundlichkeit und Laufzeit?  Um einen Einblick in diese Frage zu geben, haben wir das folgende Experiment durchgeführt. Wir haben zwei vollständige Epochen des RANDOM-Datensatzes für die drei Bibliotheken Hub, Deep Lake und Webdataset ausgeführt und dabei den Ursprung der Daten geändert. Drei Standorte wurden berücksichtigt: eine lokale Kopie auf der Maschine, auf der die Festplatte der Experimente läuft, eine Kopie in einem S3-Bucket (in der Region, die unserer Maschine am nächsten liegt) und eine in MinIO gespeicherte Kopie (ein Open-Source-Äquivalent von S3, das lokal gehostet werden kann) und auf einer ähnlichen Maschine innerhalb desselben lokalen Netzwerks ausgeführt (beide Maschinen waren über WLAN verbunden). Der Computer der Experimente hatte eine Intel(R) Core(TM) i7-7700 CPU @ 3,60 GHz, 16 GB RAM, NVIDIA GeForce RTX   2070 Rev und eine Samsung SSD 850-Festplatte mit 256 GB Speicher. In Bezug auf die Latenz dauerte die Round Trip Time von der Workstation, auf der die Experimente ausgeführt wurden, zum MinIO-Server (im selben Raum und im selben lokalen WLAN) 59,2 ± 58,5 ms (mindestens 8,8 ms), während sie zum S3-Bucket in AWS-Servern 17,3 ± 1,3 ms (mindestens 14,8 ms) dauerte.  Abbildung 10 zeigt die Gesamtlaufzeiten für die neun Experimente, und die weißen Prozentsätze bezeichnen die Verlangsamung (Erhöhung der Laufzeit) im Vergleich zum lokalen Fall. Wir können beobachten, dass, obwohl es bei Hub und Webdataset eine deutliche Steigerung beim Wechsel zu AWS gibt, Deep Lake es geschafft hat, mit einer Steigerung von nur 13 % fast die gleiche Geschwindigkeit beizubehalten. Aus dem Ergebnis ließ sich eine weitere hilfreiche Erkenntnis ziehen: Die MinIO-Einstellung zeigt eine fast doppelt so starke Verlangsamung wie die AWS-Einstellung, wie in Abbildung 10 zu sehen ist. Dieses Ergebnis könnte in erster Linie durch den Unterschied in den oben gezeigten durchschnittlichen Round Trip Times erklärt werden, was verdeutlicht, dass lokale Netzwerke (z. B. interne Unternehmensnetzwerke[8]) aufgrund ihrer komplexen Konfigurationen und Einschränkungen möglicherweise nicht die effizienteste Möglichkeit sind, Datensätze zu hosten. Darüber hinaus zeigt dieses Ergebnis auch, dass der Speicher, der die Datensätze über das Netzwerk bereitstellt, eine entscheidende Rolle bei der Ermöglichung von Remote-Training spielt und Fragen zu Best Practices zur Bereitstellung von Datensätzen aufwerfen könnte. Genauer gesagt werden Daten von S3 parallel von verschiedenen Servern mit Lastausgleich bereitgestellt, während wir Zugriff auf eine einzige MinIO-Instanz hatten.  Die Diagramme für alle weiteren Experimente finden Sie im Anhang A.  Dieses Dokument ist   . auf Arxiv unter der CC 4.0-Lizenz verfügbar  [5] https://www.seagate.com/www-content/productcontent/barracuda-fam/barracuda-new/enus/docs/100835983b.pdf  [6] in der Geschwindigkeit. Der Sampler für PyTorch wird im Voraus erstellt, was die Gesamtlaufzeit erheblich beeinflusst.  [7] Squirrel verfügt über diese Fähigkeit, aber es gelang uns nicht, eine MinIO-Adresse anzugeben, daher haben wir es vom Vergleich ausgeschlossen. Wir hatten ein ähnliches Problem mit Torchdata.  [8] In diesem Fall ein Universitätsnetzwerk

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

Serialization's blog

Dieses Audio ist in der Originalsprache der Geschichte produziert!

Zu lang; Lesen

Boost your HackerNoon story @ $159.99! 🚀

Ein Überblick über die Data-Loader-Landschaft: Numerische Ergebnisse

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon's DeFi Writing Contest with SORA Network: XSTUSD Use Cases

HackerNoon Decoded 2024: Celebrating Our Writing Community!

HackerNoon Decoded 2024: Celebrating Our Cybersecurity Community!

HackerNoon's DeFi Writing Contest with SORA Network: XSTUSD Use Cases

HackerNoon Decoded 2024: Celebrating Our Writing Community!

HackerNoon Decoded 2024: Celebrating Our Cybersecurity Community!

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps