TFF işbirlikçilerinin 24.08.2022 toplantısından notlar

TFF'de seyrek tensör desteği:
- EW - TFF'ye aktarmak istediğimiz Keras modellerimiz var, seyrek tensörleri var
  - Yoğun tensörlere basitçe eşlemek, kullanım durumumuzda kabul edilemez bellek maliyetine ve yavaşlığa neden olur, bu yüzden bundan kaçınmaya çalışıyoruz.
- TFF'de mevcut seyrek tensör desteği üzerinde ZG
  - GitHub'da bahsedilen sorunlar çoğunlukla tf.data.Dataset ile ilgili
  - Çoğunlukla başka türlü çalışır, ancak bazı DIY, özellikle wrt, bileşen tensörlerinin üçlüsü üzerinde saf bir şekilde seyrek bir toplam yapamayacağımız, istenen sonuca sahip olmayacak olan toplamalar gerektirir.
- (göreceli önemle ilgili soru)
- EW - bu bizim için engelleme değil, iyi bir performans/kaynak ayak izi optimizasyonu
- ZG - GitHub sorunlarıyla ilgili olarak, veri kümesini TFF hesaplamasının içine gizleyerek çalışabilir, bu nedenle giriş-çıkış sınırının bir parçası değildir
- KO - “çoğunlukla işe yarıyor” yorumumuzun açıklığa kavuşturulması, seyrek tensörleri yoğun tensör demetleri olarak temsil etme/işleme konusundaki yaygın uygulamaya atıfta bulunur. Veri kümeleri kullanımı için de yoğun tensör demetleri olarak seyrek ile uğraşmayı denediniz mi?
  - EW - henüz denemedim
- KO - bu konuşmada seyrek iki yerde ortaya çıktı - model parametreleri için ve aynı zamanda seyrek girdi verileri için - ikisi de eşit derecede önemli mi?
  - EW - ideal olarak her ikisine de sahip olurdu
- KO - Ewan'ın kurucu parçaları temsil eden yoğun tensör demetleriyle çalışmayı denemesi için bir eylem öğesi.
- KO - bu hala seyrek tensör işleme için daha iyi API'ler/yardımcılar hakkında bir soru bırakıyor, ancak bu özel kullanım durumunun engellemesini kaldırabilir. API hakkında düşünceleriniz?
- EW - ideal olarak bu sadece şeffaf olabilir mi (müşterinin TFF kullanan seyrek için özel bir şey yapmasına gerek yok ve sadece çalışıyor)
  - KO, ZG - bazı durumlarda, örneğin toplama için açık değildir - seyrek tensörlerin bileşenlerini toplamanın potansiyel olarak birden fazla yolu vardır, ideal olarak müşteri tarafından yapılacak bir seçim
  - KR - muhtemelen küçük bir özel "seyrek toplam" sembol ailesine sahip olmak en çok işlem yapılabilir
  - KO - belki de EW'nin ihtiyaç duyduğu seyrek toplam sürümünün prototipini oluşturarak başlayabilir ve bunu tohumlamak ve bunun üzerine inşa etmek için genel bir seyrek toplam operatörü olarak TFF'ye yükleyebiliriz (bu çevrimdışında takip etmek için - belki anlaşmazlıkta)
  - EW +1
Jeremy'nin önerisi, 2 hafta öncesinden devam ediyor:
- TFF Teknik Notu: İstemci tarafından başlatılan bağlantılar
- (toplantıdan kısa bir süre önce paylaşıldığı için herkesin daha sonra gözden geçirmesi için yapılacaklar)
- (Jeremy sunar)
- JL - bir "Bulut" ile istemci başına yürütücüler (örneğin tarayıcılarda) arasında istek alışverişi yapmak için "görev deposu" soyutlamasını önermek, ikincisi görevleri merkezi bir "görev deposundan" çeker. Başka bir bağlamda böyle bir şey düşünüldü mü?
- KR - evet, hata işleme senaryolarında
  - Yine de daha zor problemler - uygulayıcılar arasında devlet transferi zordur, Jeremy tarafından sunulan senaryoya ne kadar taşındığından emin değilim
- HV - yapraklardaki uygulayıcılar vatansız olabilir mi
  - JL - bu, onu daha çok cihazlar arası SysML kağıdı gibi yapar
- (yerel TFF protokolüne daha çok benzeyen iki yönlü akışla karşılaştırıldığında bu senaryodaki performansla ilgili soru)
- JL - gecikme hususları olduğunu kabul edin
- bazı aktarımlarda çift yönlü akış desteklenmez, bu nedenle her zaman uygun bir seçenek değildir
- (zaman tükendi)
- (2 hafta sonra devam edecek - bir sonraki toplantının ilk gündem maddesi, Jeremy katılacak)