หมายเหตุจากการประชุม 8/24/2022 ของผู้ร่วมงาน TFF

  • การสนับสนุนเทนเซอร์แบบเบาบางใน TFF:
    • EW - เรามีโมเดล Keras ที่เราต้องการพอร์ตไปยัง TFF พวกมันมีเทนเซอร์เบาบาง
      • การทำแผนที่กับเทนเซอร์ที่มีความหนาแน่นเพียงอย่างเดียวจะส่งผลให้เกิดค่าใช้จ่ายด้านหน่วยความจำและความช้าที่ไม่สามารถยอมรับได้ในกรณีการใช้งานของเรา ดังนั้นเราจึงต้องการหลีกเลี่ยงสิ่งนั้น
    • ZG กับการสนับสนุนเทนเซอร์แบบเบาบางที่มีอยู่ในTFF
      • ปัญหาที่กล่าวถึงใน GitHub ส่วนใหญ่เกี่ยวข้องกับ tf.data.Dataset
      • ส่วนใหญ่ใช้งานได้ แต่ต้องใช้ DIY โดยเฉพาะอย่างยิ่ง wrt การรวมซึ่งเราไม่สามารถทำผลรวมเบาบางอย่างไร้เดียงสาบนสามของเทนเซอร์ที่เป็นส่วนประกอบได้ซึ่งจะไม่ได้ผลลัพธ์ที่ต้องการ
    • (คำถามเกี่ยวกับความสำคัญสัมพัทธ์)
    • EW - นี่ไม่ใช่สิ่งกีดขวางสำหรับเรา แต่เป็นการเพิ่มประสิทธิภาพที่ดี/ฟื้นฟูรอยเท้า
    • ZG - เกี่ยวกับปัญหา GitHub อาจแก้ไขได้โดยการซ่อนชุดข้อมูลในการคำนวณ TFF ดังนั้นจึงไม่เป็นส่วนหนึ่งของขอบเขตอินพุต-เอาท์พุต
    • KO - ชี้แจงว่าความคิดเห็น "ส่วนใหญ่ใช้งานได้" ของเราหมายถึงแนวปฏิบัติทั่วไปในการแสดง/จัดการเทนเซอร์กระจัดกระจายเป็นทูเพิลของเทนเซอร์หนาแน่น คุณได้ลองจัดการกับ sparse เป็น tuples ของเทนเซอร์หนาแน่นสำหรับการใช้ชุดข้อมูลด้วยหรือไม่?
      • EW - ยังไม่ได้ลอง
    • KO - กระจัดกระจายในการสนทนานี้เกิดขึ้นในสองแห่ง - สำหรับพารามิเตอร์แบบจำลอง แต่สำหรับข้อมูลที่ป้อนแบบกระจัดกระจายด้วย - ทั้งคู่มีความสำคัญเท่าเทียมกันหรือไม่
      • EW - น่าจะมีทั้งคู่
    • KO - หนึ่งรายการการกระทำสำหรับ Ewan เพื่อพยายามทำงานกับ tuples ของเทนเซอร์หนาแน่นที่เป็นตัวแทนของส่วนประกอบต่างๆ
    • KO - ยังคงมีคำถามเกี่ยวกับ API/ตัวช่วยที่ดีกว่าสำหรับการจัดการเทนเซอร์แบบเบาบาง แต่สามารถปลดบล็อกกรณีการใช้งานเฉพาะนี้ได้ ความคิดเกี่ยวกับ API?
    • EW - ควรจะโปร่งใสดีไหม (ไม่จำเป็นต้องทำอะไรเป็นพิเศษเพื่อให้ลูกค้ากระจัดกระจายโดยใช้ TFF และใช้งานได้)
      • KO, ZG - ในบางกรณี ไม่ชัดเจน เช่น การรวม - มีความเป็นไปได้มากกว่าหนึ่งวิธีในการรวมส่วนของเทนเซอร์แบบกระจัดกระจาย ซึ่งเป็นทางเลือกที่ลูกค้าควรเลือก
      • KR - อาจมีกลุ่มเล็ก ๆ ที่มีสัญลักษณ์ "ผลรวมเบาบาง" ที่สามารถดำเนินการได้มากที่สุด
      • KO - บางทีเราอาจเริ่มต้นด้วยการสร้างต้นแบบเวอร์ชันของผลรวมเบาบางที่ EW ต้องการและอัพสตรีมไปยัง TFF เป็นตัวดำเนินการผลรวมแบบกระจายทั่วไปเพื่อเริ่มต้นสิ่งนี้ และสร้างต่อจากนั้น (เพื่อติดตามในออฟไลน์นี้ - อาจเป็นความไม่ลงรอยกัน)
      • EW +1
  • ข้อเสนอของ Jeremy ต่อเมื่อ 2 สัปดาห์ก่อน:
    • TFF Tech Note: การเชื่อมต่อที่เริ่มต้นโดยไคลเอ็นต์
    • (Todo ให้ทุกคนทบทวนทีหลังเพราะเพิ่งแชร์ไม่นานก่อนการประชุม)
    • (เจเรมีกำลังนำเสนอ)
    • JL - เสนอ "ที่เก็บงาน" ที่เป็นนามธรรมสำหรับการแลกเปลี่ยนคำขอระหว่าง "คลาวด์" และตัวดำเนินการต่อลูกค้า (เช่น ในเบราว์เซอร์) โดยที่ส่วนหลังจะดึงงานจาก "ที่เก็บงาน" แบบรวมศูนย์ มีการพิจารณาสิ่งนี้ในบริบทอื่นหรือไม่?
    • KR - ใช่ ในสถานการณ์การจัดการความล้มเหลว
      • แม้ว่าจะมีปัญหาอื่นๆ อีกมาก - การถ่ายโอนสถานะระหว่างผู้บริหารเป็นเรื่องยาก ไม่แน่ใจว่าจะนำสถานการณ์ที่ Jeremy นำเสนอไปมากน้อยเพียงใด
    • HV - ผู้ดำเนินการในใบไม้สามารถเป็นคนไร้สัญชาติได้หรือไม่?
      • JL - สิ่งนี้จะทำให้เหมือนกระดาษ SysML บน cross-device . มากขึ้น
    • (คำถามเกี่ยวกับประสิทธิภาพในสถานการณ์นี้ เมื่อเทียบกับการสตรีมแบบสองทิศทางในลักษณะที่ใกล้เคียงกับโปรโตคอล TFF ดั้งเดิมมากขึ้น)
    • JL - ยอมรับว่ามีข้อควรพิจารณาเกี่ยวกับเวลาแฝง
    • ไม่รองรับการสตรีมแบบสองทิศทางในการขนส่งบางอย่าง ดังนั้นจึงไม่ใช่ตัวเลือกที่ทำงานได้เสมอไป
    • (หมดเวลาแล้ว)
    • (จะดำเนินต่อไปใน 2 สัปดาห์ - วาระแรกสำหรับการประชุมครั้งต่อไป Jeremy จะเข้าร่วม)