TFF सहयोगियों की 8/24/2022 बैठक के नोट्स

  • TFF में विरल टेंसर समर्थन:
    • EW - हमारे पास Keras मॉडल हैं जिन्हें हम TFF में पोर्ट करना चाहते हैं, उनके पास विरल टेंसर हैं
      • बस घने टेंसर में मैप करने से हमारे उपयोग के मामले में अस्वीकार्य मेमोरी लागत और धीमा हो जाता है, इसलिए हम इससे बचना चाहते हैं
    • TFF में मौजूदा विरल टेंसर समर्थन पर ZG
      • GitHub पर उल्लिखित मुद्दे ज्यादातर tf.data.Dataset . से संबंधित हैं
      • अधिकतर अन्यथा काम करता है, लेकिन इसके लिए कुछ DIY, विशेष रूप से wrt, समेकन की आवश्यकता होती है जहां हम घटक टेंसर के ट्रिपल पर केवल भोलेपन से एक विरल योग नहीं कर सकते हैं, जिसका वांछित परिणाम नहीं होगा
    • (सापेक्ष महत्व के बारे में प्रश्न)
    • EW - यह हमारे लिए अवरुद्ध नहीं है, बल्कि एक अच्छा प्रदर्शन/संसाधन पदचिह्न अनुकूलन है
    • जेडजी - गिटहब मुद्दों के संबंध में, टीएफएफ गणना के अंदर डेटासेट छुपाकर काम कर सकता है, इसलिए यह इनपुट-आउटपुट सीमा का हिस्सा नहीं है
    • KO - यह स्पष्ट करते हुए कि हमारी "यह ज्यादातर काम करती है" टिप्पणी विरल टेंसरों के टुपल्स के रूप में विरल टेंसर का प्रतिनिधित्व / संचालन करने के सामान्य अभ्यास को संदर्भित करती है। क्या आपने डेटासेट के उपयोग के लिए घने टेंसर के टुपल्स के रूप में विरल से निपटने की कोशिश की है?
      • EW - अभी तक कोशिश नहीं की है
    • KO - इस बातचीत में विरल दो स्थानों पर आया है - मॉडल मापदंडों के लिए, लेकिन विरल इनपुट डेटा के लिए भी - क्या दोनों समान रूप से महत्वपूर्ण हैं?
      • ईडब्ल्यू - आदर्श रूप से दोनों होंगे
    • KO - ईवान के लिए एक क्रिया आइटम जो घटक भागों का प्रतिनिधित्व करने वाले घने टेंसरों के टुपल्स के साथ काम करने का प्रयास करता है।
    • केओ - यह अभी भी स्पैस टेंसर हैंडलिंग के लिए बेहतर एपीआई/हेल्पर्स के बारे में एक प्रश्न छोड़ देता है, लेकिन इस विशेष उपयोग के मामले को अनब्लॉक कर सकता है। एपीआई पर विचार?
    • ईडब्ल्यू - आदर्श रूप से यह सिर्फ पारदर्शी हो सकता है (टीएफएफ का उपयोग कर ग्राहक द्वारा स्पैस के लिए कुछ विशेष करने की आवश्यकता नहीं है और यह सिर्फ काम करता है)
      • KO, ZG - कुछ मामलों में, यह स्पष्ट नहीं है, उदाहरण के लिए, एकत्रीकरण के लिए - विरल टेंसर के घटक भागों को एकत्रित करने के लिए संभावित रूप से एक से अधिक तरीके हैं, एक विकल्प आदर्श रूप से ग्राहक द्वारा बनाया जाना है
      • केआर - शायद समर्पित "विरल राशि" प्रतीकों का एक छोटा परिवार होने के कारण सबसे अधिक कार्रवाई योग्य है
      • केओ - शायद हम ईडब्ल्यू द्वारा आवश्यक स्पैस योग के संस्करण को प्रोटोटाइप करके शुरू कर सकते हैं और इसे सीड करने के लिए एक सामान्य स्पैस योग ऑपरेटर के रूप में टीएफएफ को अपस्ट्रीम कर सकते हैं, और उस पर निर्माण कर सकते हैं (इस ऑफ़लाइन पर अनुवर्ती - शायद विवाद पर)
      • ईडब्ल्यू +1
  • जेरेमी का प्रस्ताव, 2 सप्ताह पहले से जारी:
    • टीएफएफ टेक नोट: क्लाइंट द्वारा शुरू किए गए कनेक्शन
    • (सभी के लिए बाद में इसकी समीक्षा करने के लिए कार्य करें क्योंकि इसे बैठक से कुछ समय पहले ही साझा किया गया था)
    • (जेरेमी पेश कर रहा है)
    • JL - "क्लाउड" और प्रति-क्लाइंट निष्पादकों (जैसे, ब्राउज़रों में) के बीच अनुरोधों के आदान-प्रदान के लिए "टास्क स्टोर" एब्स्ट्रैक्शन का प्रस्ताव करना, बाद में एक केंद्रीकृत "टास्क स्टोर" से कार्यों को खींचना। क्या किसी अन्य संदर्भ में ऐसा कुछ माना गया है?
    • केआर - हाँ, विफलता से निपटने के परिदृश्य में
      • अधिक बालों वाली समस्याएं, हालांकि - निष्पादकों में राज्य हस्तांतरण मुश्किल है, यह सुनिश्चित नहीं है कि जेरेमी द्वारा प्रस्तुत परिदृश्य पर कितना असर पड़ता है
    • एचवी - क्या पत्तियों में निष्पादक स्टेटलेस हो सकते हैं
      • JL - यह इसे क्रॉस-डिवाइस पर SysML पेपर की तरह बना देगा
    • (इस परिदृश्य में प्रदर्शन के बारे में प्रश्न, द्वि-दिशात्मक स्ट्रीमिंग की तुलना में इस तरह से जो मूल TFF प्रोटोकॉल से अधिक निकटता से मिलता-जुलता है)
    • जेएल - एके कि विलंबता विचार हैं
    • द्वि-दिशात्मक स्ट्रीमिंग कुछ परिवहन में समर्थित नहीं है, इसलिए हमेशा एक व्यवहार्य विकल्प नहीं है
    • (समय समाप्त हो गया)
    • (2 सप्ताह में जारी रखा जाना - अगली बैठक के लिए एजेंडा का पहला बिंदु, जेरेमी शामिल होंगे)