Veri Yükleyici Ortamına Genel Bakış: Deneysel Kurulum

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ı

3. DENEYSEL KURULUM

Özelliklerini ve performanslarını karşılaştırmak için çeşitli kitaplıklar ve veri kümeleri seçildi. Her ne kadar mümkün olduğunca anlaşılır olmaya çalışılsa da veri yükleme alanı sürekli olarak gelişmekte ve her gün yeni kütüphaneler ve sürümler eklenmektedir. Bu bağlamda, aşağıdaki listenin, genel olarak en iyiyi iddia etmeden veya bulmadan (muhtemelen bu yazının yazıldığı zamandan yayınlandığı zamana kadar değişecektir) veri yükleyicilerin mevcut yeteneklerine dair iyi bir genel bakış sunmasını bekliyoruz. Deneylerin tüm kaynak kodlarını kamuya açık hale getiriyoruz ve sonuçların tamamen tekrarlanabilir olmasını bekliyoruz.

Deneylerimizi gerçekleştirmek için yedi kütüphane seçtik: PyTorch (Paszke ve diğerleri, 2019), Torchdata (TorchData, 2021), Hub (Team, 2022a), FFCV (Leclerc ve diğerleri, 2022), Webdatasets (Webdataset, 2013), Sincap (Takım, 2022b) ve Derin Göl (Hambardzumyan ve diğerleri, 2022). Keşfettiğimiz ilginç şeylerden biri de tüm kitaplıkların aynı özellikleri desteklememesidir. Örneğin, uzaktan deneylerimizi gerçekleştirmek için FFCV'yi S3 klasöründe barındırılan bir veri kümesiyle çalıştıramadık. Bölüm 1'de bahsettiğimiz gibi tüm deneylerimizi PyTorch'ta gerçekleştiriyoruz. Deneyleri diğer popüler makine öğrenimi çerçevelerinde yeniden üretmeyi düşündük, ancak ikinci adayın Tensorflow olacağı için bu fikre karşı çıktık, ancak Google'ın bundan JAX lehine uzaklaştığı yönünde söylentiler var. Şekil 1, farklı ML çerçevelerinin son 12 aydaki popülerliğini göstermektedir.

3.1 Veri Kümeleri

Veri kümeleriyle ilgili olarak, başlangıçta iki farklı öğrenme görevini desteklemek için iki klasik veri kümesini tercih ettik: görüntü sınıflandırma için CIFAR-10 (Krizhevsky ve diğerleri, 2009) ve nesne tespiti için CoCo (Lin ve diğerleri, 2014). Bazı deneyler yaparken aşağıdakilerle açıklanabilecek garip davranışlar (kütüphanelerin beklenenden daha iyi performans göstermesi) gözlemledik.

CIFAR-10 belleğe sığıyor[2]. Bu nedenle, 256 x 256 piksel boyutunda rastgele oluşturulmuş renkli görüntülerden ve 20 üzerinden rastgele bir sınıftan oluşan RANDOM adında üçüncü bir veri kümesi oluşturduk. Bu üçüncü veri kümesi, eğitim için 45000, doğrulama için 5000 ve test için 500 görüntü içeriyor. ve CIFAR-10'dan oldukça büyüktür.

Karşılaştırmaları karşılaştırılabilir hale getirmek için tüm kütüphaneler için aynı dönüşümleri kullandık. Bunun tek istisnası, farklı dönüşümlerin kendi uygulamasına sahip olan FFCV'dir. Görüntü sınıflandırması için dönüşüm yığını aşağıdakilerden oluşuyordu: Rastgele Yatay Çevirme, Normalleştirme, Kesme, Tensöre Dönüştürme.

Nesne tespiti için çoğunlukla Albümentations'ın (Buslaev ve diğerleri, 2020) dönüşüm uygulamasına güvendik. Yığın şu şekilde görünüyordu: Rastgele Boyutlu Kırpma, Rastgele Yatay Çevirme, Normalleştirme, Tensöre Dönüştürme. Bu dönüşümler hem görüntülere hem de sınırlayıcı kutulara uygulanır.

3.2 Deney Varyantları

Mümkün olduğunda veri kümesini yerel olarak ve S3'e eşdeğer bir pakette barındırdık. Bu, ağ üzerinden bir veri akışından eğitimden kaynaklanan yavaşlamayı değerlendirmemize olanak sağladı. Bölüm 4'te eğitim ortamının ayrıntılı bir açıklamasını sunacağız.

En yoğun eğitim işlerinin birden fazla GPU kullanmayı gerektirdiği göz önüne alındığında, mümkün olduğunda aynı deneyleri birden fazla GPU ünitesinin bulunduğu bir ortamda da yürüttük. Deneyleri yürüttüğümüz sırada tüm kütüphaneler PyTorch Lightning'in tam desteğine sahip olmadığından, PyTorch'un Dağıtılmış Veri Paralel (DDP) (Li ve diğerleri, 2020) kütüphanesini kullanarak çoklu GPU'yu uygulamaya karar verdik.

Bazı makine öğrenimi projeleri için daha büyük bir veri kümesinin yalnızca bir alt kümesine erişmemiz gerekebilir. Bu gibi durumlarda, tüm veri kümesi üzerinde yineleme yapmak zorunda kalmadan gerekli veri noktalarını hızlı bir şekilde filtreleme yeteneğine sahip olmak, toplam eğitim süresini büyük ölçüde azaltabilir. Bazı kitaplıklar, sınıf gibi (görüntü sınıflandırma görevleri için) belirli özelliklere dayalı filtrelemeye izin verir. Kütüphane tarafından sağlanan filtreleme yöntemini kullanmanın (eğer öneriliyorsa) ve hiç filtrelememenin hızdaki kazancını (veya kaybını) araştırdık. Kütüphane bir filtreleme yöntemi sunmadığında, bunları saf bir şekilde uyguladık, yani tüm veri kümesini tarayıp yalnızca belirtilen koşulla eşleşen öğeleri tuttuk. Tüm numuneler üzerinde yinelemeyi önlemek için indeks benzeri ek bir yapının korunmasını gerektirdiğinden, hızlı filtrelemenin uygulanması mutlaka önemsiz değildir.

Son olarak Tablo 1, farklı kitaplıkların bu yazıda incelediğimiz farklı deneyler ve veri kümeleriyle uyumluluğunu belirtir.

3.3 Metrikler

Deneyleri oluştururken temel önceliğimiz, tüm farklı kütüphaneleri sağlam bir şekilde karşılaştırmamıza olanak sağlayacak objektif bir ölçüm bulmaktı.

İdeal ölçüm, eğitim işinin toplam çalışma süresi olurdu çünkü beklememiz ve ödememiz gereken şey bu. Ne yazık ki bu, yapabileceğimiz deneylerin sayısını büyük ölçüde sınırlayacaktı. Dikkatli bir değerlendirmenin ardından, sayısal deneylerimizle desteklenen bir sonuç olarak, saniyede işlenen veri noktalarının (görüntülerin) sayısını seçtik. Bu metriğin iki değişkenini göz önünde bulunduruyoruz: birinde eğitim için ML modelini kullanıyoruz ve geri yayılım gerçekleştiriyoruz; diğeri ise ML modelini kullanmadığımız ve yalnızca örnekler üzerinde yineleyerek bunları GPU'ya kopyaladığımız. İki ölçüm arasındaki fark, Algoritma 1'deki eğitim döngüsünün sözde kodundan anlaşılabilir; burada m, hız değişkenini belirtir. Ayrıca toplam çalıştırma süresini[3] ve veri yükleyicilerin başlatılması için geçen süreyi de topladık. İkincisi, bazı kütüphanelerin eğitim sırasında hızlarını artırmak için pahalı hesaplamaları önceden gerçekleştirebileceği gerçeğiyle motive edildi. Ayrıca hızı hesaplamak için bir ısınma gerçekleştirdik. Bu konu Alt Bölüm 3.5'te daha detaylı tartışılmaktadır.

3.4 Hız ve çalışma süresi arasındaki ilişki

3.5 Çalışma sürelerine daha yakından bakış

Her kitaplıktaki iç mekanizmalara ilişkin anlayışımızı artırmak için, tek bir çalıştırmada her bir toplu işlemin yürütülmesinin ve veri yükleyicinin başlatılmasının ne kadar sürdüğünü incelemeye karar verdik. Şekil 3, tek bir parametre kombinasyonu [4] için, Algoritma 1 tarafından açıklanan adımlarda her kitaplığın harcadığı süreyi gösterir. Tüm bu deneyler, 10 seriden sonra bir kesintiyi içeriyordu.

İlginç bir şekilde, ilk parti diğerlerinden çok daha uzun sürüyor. Bu şu şekilde açıklanabilir: Veri yükleyicilerin çoğu bu noktada tembel yükleme verilerine güvendiğinden, gelecekteki çağrılar önceden alma, halihazırda bellekte bulunan veriler ve paralelleştirmeden (GPU hesaplamalarla meşgulken işlerin yapılması) faydalanacaktır.

1'den 9'a kadar olan bantların boyutu, bir kütüphanede geçen süreden bu yana her kütüphanenin ne kadar iyi ölçeklendiğine dair en iyi göstergeyi sağlar.

büyük veri kümesi bu genişlikle doğrusal olarak büyür. Çoğu kütüphanenin tekdüze bir genişliğe sahip olduğunu, Deep Lake'in en kısa (en hızlı) olduğunu gözlemleyebiliriz. Öte yandan homojen olmayan genişlikleri gösteren tek kütüphane FFCV'dir; burada 1'den 3'e kadar olan bantlar görüntüde görülemeyecek kadar incedir.

Tamamlama süresi, oldukça uzun süren FFCV ve Deep Lake dışındaki tüm kütüphaneler için hemen hemen aynı süreyi alır. Tamamlama için harcanan zaman çoğunlukla modele bağlıdır ve her kitaplığın ne kadar iyi ölçeklendirildiğinin göstergesi olmayabilir.

Bu rakama dayanarak hızı hesaplarken bir ısınma yapmaya karar verdik. Bu, tüm hız hesaplamalarında ilk partinin harcadığı zamanın göz ardı edilmesi anlamına gelir.

[2] Bu, bazı inceleme literatüründe genellikle istenen ve beklenen bir şeydir, ancak küçük ekipleri ve şirket içi iş istasyonlarını içeren çeşitli pratik uygulamalarda durumun böyle olmadığını gördük.

[3] Bu, simülasyonun başlangıcından kesime kadar olan süredir ve pratikte genellikle yalnızca 10 partidir.

[4] RASTGELE veri kümesi, tek GPU, 0 çalışan, toplu iş boyutu 64