Yazarlar:  (1) Iason Ofeidis, Elektrik Mühendisliği Bölümü ve Yale Ağ Bilimi Enstitüsü, Yale Üniversitesi, New Haven {Eşit katkı};  (2) Diego Kiedanski, Elektrik Mühendisliği Bölümü ve Yale Ağ Bilimi Enstitüsü, Yale Üniversitesi, New Haven {Eşit katkı};  (3) Leandros Tassiulas Levon Ghukasyan, Activeloop, Mountain View, CA, ABD, Elektrik Mühendisliği Bölümü ve Yale Ağ Bilimi Enstitüsü, Yale Üniversitesi, New Haven.  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.   Bu makale   . arxiv'de CC 4.0 lisansı altında mevcuttur  [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

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

Bu ses hikayenin orijinal dilinde üretilmiştir!

Çok uzun; Okumak

Boost your HackerNoon story @ $159.99! 🚀

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

About Author

YORUMLAR

ETİKETLERİ ASIN

BU YAZI

Related Stories

HackerNoon Kendi Ana Dilinizde 🆕 ‼️ Teknoloji Blog Yazıları için 77 Dil Ana Sayfası

Dijital Göçebeler Dinleyin: Tayland'ın Yeni DTV Vizesi Hakkında Bilmeniz Gerekenler

HackerNoon Yazma Yarışmasını mı Kazanmak İstiyorsunuz? İşte #crypto-api Yarışması Kazananlarının Önerileri

HackerNoon Kendi Ana Dilinizde 🆕 ‼️ Teknoloji Blog Yazıları için 77 Dil Ana Sayfası

Dijital Göçebeler Dinleyin: Tayland'ın Yeni DTV Vizesi Hakkında Bilmeniz Gerekenler

HackerNoon Yazma Yarışmasını mı Kazanmak İstiyorsunuz? İşte #crypto-api Yarışması Kazananlarının Önerileri

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps