Veri Yükleyici Ortamına Genel Bakış: Sayısal Sonuçlar

Bağlantı Tablosu

• Özet ve Giriş
• Veri yükleyiciler
• Deneysel kurulum
• Sayısal sonuçlar
• Tartışma
• Alakalı iş
• Sonuç, Teşekkür ve Referanslar
• A. Sayısal Sonuçlar Devamı

4. SAYISAL SONUÇLAR

İlk deney grubu için, işçi sayısını (bkz. 2) ve toplu iş boyutunu değiştirirken tüm kitaplıkların performansını değerlendirdik. Bu deneyler aşağıdaki özelliklere sahip yerel bir sunucuda gerçekleştirildi: Intel(R) Core(TM) i9-10900K, 2 x NVIDIA GeForce RTX 3090 ve 10 TB depolama alanına (6 GB/s) sahip bir HDD [5].

Üç modu değerlendirdik: 0, 1 ve 2 çalışanın tüm olası kombinasyonları için varsayılan (tek GPU), dağıtılmış (iki GPU) ve filtreleme (tek GPU). CIFAR10 ve RANDOM için parti boyutu 16, 64 veya 128'di. CoCo için daha küçük değerler kullandık: 1, 2 ve 4. Tüm bu deneylerde 10'luk bir kesim noktası ve modeli çalıştıran değişken (ileri ve ileri) kullanıldı. geriye doğru geçiş).

4.1 Parti büyüklüğünün ve çalışanların bir fonksiyonu olarak hız

Deneyleri incelerken ilk fark ettiğimiz şey, kütüphaneler arasındaki varyansın probleme ve kullanılan veri setine bağlı olmasıdır. Şekil 4, tek bir GPU'da CIFAR10 için böyle bir karşılaştırmayı gösterirken, Şekil 5, yine tek bir GPU'da CoCo için aynı sonucu göstermektedir.

İkincisinde ileri ve geri pasın hesaplanması için harcanan zamanın toplam koşu süresine hakim olduğu göz önüne alındığında bu beklenen bir durumdu; görüntü için durum böyle değildi.

sınıflandırma. Ayrıca hızdaki genel farkı da fark edebilirsiniz: saniyede 4000 örnekten yalnızca 20'ye.

İkinci olarak, parti boyutunun arttırılmasının hemen hemen her durumda işlem hızını arttırdığını belirtiyoruz. Ancak çalışan sayısı açısından durum böyle değil. Şekil 6'da, çalışan sayısı arttıkça FFCV performansının düştüğünü, Deep Lake'in ise 2 değil 1 çalışanda sabitlendiğini gözlemleyebiliriz. Bunun bir açıklaması, kütüphanelerin iş parçacıklarını ve süreçleri gerektiği gibi nasıl dağıtacaklarına karar veren kendi dahili algoritmalarına sahip olmalarıdır. Yukarıdaki nokta bu kütüphanelerin kullanıcıları için geçerlidir; çünkü bunlardan birinde yaşanan deneyim diğerine iyi bir şekilde aktarılamayabilir.

4.2 DDP Kullanırken Hız Artışları

Bir veri yükleyicinin arzu edilen bir özelliği, GPU sayısıyla doğrusal olarak ölçeklenebilme yeteneğidir. Bu her zaman mümkün değildir ve her kitaplığın dahili yükleme mekanizmasına bağlıdır. Bir veya iki GPU kullanıldığında hız artışını karşılaştırarak bu kitaplıkların nasıl performans gösterdiğini araştırıyoruz. Şekil 7 RANDOM veri kümesinin sonuçlarını göstermektedir. Her çubuk, tüm parti boyutları, çalışan sayısı ve tekrarlarda elde edilen maksimum hızı temsil eder. Bu bir bakıma kütüphanenin ulaşabileceği maksimum hızı yansıtıyor. Kütüphanelerin ortalama %40 oranında hızlandığını, yani doğrusal artışın yarısından azını gözlemliyoruz. İki vaka özellikle şaşırtıcıdır. Bir yandan Torchdata, iki GPU ile tek GPU'ya göre daha kötü performans gösteriyor. Öte yandan FFCV teorik olarak mümkün olanın üzerinde bir hız artışı elde etti. Burada rol oynayabilecek çeşitli yapılar var, ancak büyük olasılıkla bunun nedeni, çalıştırabildiğimiz sınırlı sayıda tekrardan kaynaklanıyor (sınırlı kaynaklar nedeniyle). Ayrıca bu olabilir

Torchdata'da bir yanlış yapılandırmayı belirtir: çoklu GPU ortamlarında deney çalıştırmaya ilişkin belgeler çoğu kitaplık için sınırlıdır.

4.3 İleri ve geri paslı ve passız karşılaştırma

Algoritma 1'i sunarken tartıştığımız gibi, ileri ve geri pasları hız hesaplamasına dahil edip etmeyeceğimize karar vermemiz gerekiyordu. Her ikisinin de argümanları var. Bir yandan ileri ve geri geçişler dahil olmak üzere algoritmanın gerçek eğitim süresini daha iyi yansıtır. Aynı zamanda, bazı kütüphaneler ileri geçiş sırasında normalde gerçekleştirilen adımları önleyici olarak optimize edebilir.

orada durmak, sanki yaptıklarından daha uzun sürüyormuş gibi görünüyor.

Öte yandan, ileri ve geri geçişte geçen süre, yalnızca verinin yüklenmesi için gereken süreden çok daha büyükse, bu sürenin hesaplamaya dahil edilmesi, kaçınılmaz olarak kütüphaneler arasındaki farkı gizleyecektir.

Davranış değişikliğinin fark edilebilir olup olmadığını anlamak için, iki model işlemi hesaplamaya dahil ederken ve içermediğinde ortalama hızdaki farkı karşılaştırmak için RANDOM veri kümesini kullandık. Sonuçlar Şekil 8'de sunulmaktadır. Model hariç tutulduğunda çoğu kütüphanenin hızının biraz arttığını (performansı yarıya düşen FFCV hariç) ve en önemlisi kütüphaneler arasındaki göreceli performansın hemen hemen aynı kaldığını gözlemleyebiliyoruz.

4.4 Verileri filtrelerken hız dengelemeleri

Filtreleme deneylerimiz için CIFAR10 ve RANDOM için tutulacak iki sınıf seçtik: köpek ve kamyon ve sırasıyla 0 ve 13. CoCO için üç sınıf seçtik: pizza, kanepe, kedi.

Çoğu kütüphanenin, tüm veri kümesi üzerinde yineleme yapılmasını önleyen iyi bir filtreleme mekanizmasına sahip olmadığını gözlemledik. Örneğin, PyTorch filtreleme uygulamamız, istenen görüntülerin indeksleriyle özel bir örnekleyici oluşturmayı gerektirir.

Bu, küçük bir veri kümesi için oldukça hızlıdır, ancak büyük veri kümeleri için mümkün olmaz: CoCo'yu PyTorch kullanarak filtrelemek aşırı derecede pahalıydı. Genel olarak, filtreleme sırasında ve filtreleme yapılmadığında performans oldukça benzerdi[6]. Şekil'e benzer şekilde

Şekil 7'de, Şekil 9'da filtrelemenin bir sonucu olarak yavaşlamayı görebiliyoruz: Torchdata ve Webdataset için kayda değer olmasına rağmen, CoCo Veri Seti ile çalışırken sonuçların tersine döndüğünü gördük.

4.5 Ağ üzerinden akış sırasında eğitim

İdeal olarak, veri kümesi depolama alanını makine öğrenimi eğitim sürecinden ayırabilir ve verilerimizi saklayan veritabanını, ikisinin nerede olduğuna bakılmaksızın, tercih edilen ML çerçevesine kolayca bağlayabiliriz. Bu, eğitim verilerinin bir ağ üzerinden gönderilmesini ve önemli ölçüde hız kaybını içerir. Bulutta GPU hızlandırmalı donanım kiralamanın yüksek maliyetleri göz önüne alındığında, bu kolaylık buna değmeyecek gibi görünebilir. Ama öyle değil mi?

Bu yazıda ele alınan kütüphanelerden bazıları internet üzerinden erişilebilen bir veri kümesinin belirlenmesine izin vermektedir: Web veri kümesi, Hub ve Deep Lake bu konuda özellikle iyidir[7]. O zaman şu soru ortaya çıkıyor: Kullanım kolaylığı ile çalışma süresi arasındaki fark ne kadar büyük?

Bu soruya biraz fikir vermek için aşağıdaki deneyi hazırladık. Verilerin kaynağını değiştirirken Hub, Deep Lake ve Webdataset olmak üzere üç kitaplık için RANDOM veri kümesinin iki tam dönemini çalıştırdık. Üç konum dikkate alındı: deneylerin sabit diskini çalıştıran makinedeki yerel bir kopya, bir S3 klasöründeki bir kopya (makinemize en yakın bölgede) ve MinIO'da saklanan bir kopya (S3'ün açık kaynaklı eşdeğeri) Yerel olarak barındırılan) aynı yerel ağdaki benzer bir makinede çalışıyor (her iki makine de WiFi aracılığıyla bağlıydı). Deneylerin bilgisayarında Intel(R) Core(TM) i7-7700 CPU @ 3,60GHz, 16 GB RAM, NVIDIA GeForce RTX vardı

2070 Rev ve 256 GB depolama alanına sahip bir Samsung SSD 850 sabit disk. Gecikmeyle ilgili olarak, deneyleri çalıştıran iş istasyonundan MinIO sunucusuna (aynı odada ve aynı yerel Wi-Fi'de bulunan) Gidiş-Dönüş Süresi 59,2 ± 58,5 ms (min. 8,8 ms) alırken, AWS'deki S3 paketine gidiş-dönüş süresi 59,2 ± 58,5 ms (min. 8,8 ms) sürdü. sunucular 17,3 ± 1,3 ms (min. 14,8 ms) sürdü.

Şekil 10, dokuz deneyin toplam çalışma süresini göstermektedir ve beyaz yüzdeler, yerel duruma kıyasla yavaşlamayı (çalışma süresindeki artışı) göstermektedir. Hub ve Webdataset için AWS'ye geçişte ciddi bir artış olmasına rağmen Deep Lake'in sadece %13'lük bir artışla neredeyse aynı hızı korumayı başardığını gözlemliyoruz. Sonuçtan başka bir faydalı fikir çıkarılabilir: Şekil 10'da görüldüğü gibi MinIO ayarı, AWS ayarından neredeyse iki kat daha kötü bir yavaşlama gösteriyor. Bu çıktı öncelikle yukarıda gösterilen ortalama Gidiş-Dönüş Sürelerindeki farkla açıklanabilir; yerel ağlar (örneğin şirket içi ağlar[8]), karmaşık yapılandırmaları ve kısıtlamaları nedeniyle veri kümelerini barındırmanın en etkili yolu olmayabilir. Ayrıca bu sonuç, veri kümelerine ağ üzerinden hizmet veren depolamanın, uzaktan eğitimin sağlanmasında önemli bir rol oynadığını ve veri kümelerine hizmet etmek için en iyi uygulamalara ilişkin soruları tetikleyebileceğini de göstermektedir. Yani, tek bir MinIO örneğine erişimimiz varken, S3'teki veriler yük dengeleme ile farklı sunuculardan paralel olarak sunuluyor.

Tüm ilave deneylere ait grafikler Ek A'da bulunabilir.

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

[6] hızda. PyTorch için örnekleyicinin oluşturulması önceden yapılır ve bu da toplam çalışma süresini önemli ölçüde etkiler.

[7] Squirrel'ın bu yeteneği var ancak MinIO adresini belirtmeyi başaramadığımız için onu karşılaştırmanın dışında bıraktık. Torchdata'da da benzer bir sorun yaşadık.

[8] Bu durumda bir üniversite ağı