การมีส่วนร่วมใน OpenXLA

ทุกคนสามารถมีส่วนร่วมใน OpenXLA และเราให้ความสำคัญกับการมีส่วนร่วมของทุกคน คุณร่วมให้ข้อมูลได้หลายวิธีดังนี้

• การตอบคำถามในฟอรัมการสนทนาของ OpenXLA (openxla-discuss)

• การปรับปรุงหรือขยายเอกสารประกอบของ OpenXLA

• การมีส่วนร่วมในฐานของโค้ดของ OpenXLA

• การมีส่วนร่วมในลักษณะใดก็ตามข้างต้นกับระบบนิเวศของไลบรารีที่กว้างขึ้น ซึ่งสร้างขึ้นบน OpenXLA

โปรเจ็กต์ OpenXLA ปฏิบัติตาม หลักเกณฑ์ของชุมชนโอเพนซอร์สของ Google

ก่อนเริ่มต้น

ลงนามในข้อตกลงการอนุญาตให้ใช้สิทธิสำหรับผู้มีส่วนร่วม

การมีส่วนร่วมในโปรเจ็กต์นี้ต้องมาพร้อมกับข้อตกลงอนุญาตให้ใช้เนื้อหาของผู้มีส่วนร่วม (CLA) คุณ (หรือนายจ้างของคุณ) ยังคงมีลิขสิทธิ์ในผลงานของคุณ เพียงแต่การลงนามในข้อตกลงนี้จะ ให้สิทธิ์เราในการใช้และแจกจ่ายผลงานของคุณเป็นส่วนหนึ่งของ โปรเจ็กต์

หากคุณหรือนายจ้างปัจจุบันได้ลงนามใน CLA ของ Google แล้ว (แม้ว่าจะเป็นสำหรับโปรเจ็กต์อื่น) คุณก็อาจไม่จำเป็นต้องลงนามอีก

ไปที่ <https://cla.developers.google.com/> เพื่อดูข้อตกลงปัจจุบันหรือลงนามในข้อตกลงใหม่

อ่านหลักจรรยาบรรณ

โปรเจ็กต์นี้เป็นไปตามหลักจรรยาบรรณของ TensorFlow

กระบวนการมีส่วนร่วม

คู่มือนักพัฒนา

ดูคำแนะนำเกี่ยวกับวิธีตั้งค่าสภาพแวดล้อมการพัฒนาสำหรับ OpenXLA ซึ่งรวมถึง การรับโค้ด การสร้าง การเรียกใช้การทดสอบ และการส่งการเปลี่ยนแปลงได้ที่ คู่มือนักพัฒนาซอฟต์แวร์

คู่มือการมีส่วนร่วม

สถาปัตยกรรมของคอมไพเลอร์ประกอบด้วยคอมโพเนนต์ต่อไปนี้

การเพิ่มประสิทธิภาพผ่าน

การเพิ่มประสิทธิภาพจะดำเนินการเปลี่ยนรูปแบบใน HLO เพื่อเพิ่มประสิทธิภาพการคำนวณ การเปลี่ยนแปลงเหล่านี้ครอบคลุมตั้งแต่การปรับปรุงระดับสูงที่ไม่ขึ้นกับสถาปัตยกรรม ไปจนถึงการปรับแต่งเฉพาะฮาร์ดแวร์ (เช่น สำหรับ GPU ของ NVIDIA)

สิ่งที่เรายอมรับโดยทั่วไปมีดังนี้

• ผ่านการทดสอบที่ใช้กับภาระงานหลายอย่าง และแสดงให้เห็นถึงผลลัพธ์เชิงบวกที่ชัดเจนและ สำคัญต่อการเปรียบเทียบประสิทธิภาพ

โดยทั่วไปเราจะปฏิเสธเนื้อหาต่อไปนี้

• การส่งผ่านที่ทำการเพิ่มประสิทธิภาพที่ไม่ซ้ำกันซึ่งกำหนดเป้าหมายไปยังโมเดลที่เฉพาะเจาะจง

บัตรฟิวชัน

ฟิวชันเป็นการเพิ่มประสิทธิภาพที่สำคัญซึ่งรวมการดำเนินการ HLO หลายรายการไว้ในเคอร์เนลเดียวเพื่อลด I/O ของหน่วยความจำและค่าใช้จ่ายในการเปิดตัวเคอร์เนล

ควรเพิ่มการ์ดฟิวชันทั้งหมดลงในไปป์ไลน์ฟิวชันเท่านั้น ไม่ใช่ก่อนหรือหลัง นอกจากนี้ยังหมายความว่าโมดูล HLO ที่เพิ่มประสิทธิภาพล่วงหน้าไม่ควรมี คำสั่งฟิวชัน หากมีการรวมกันตั้งแต่เนิ่นๆ ในไปป์ไลน์ การรวมกันนั้นจะกลายเป็น อุปสรรคสำหรับพาสการเพิ่มประสิทธิภาพ หากฟิวชันเกิดขึ้นช้า เราจะสูญเสีย ความสามารถในการเลือกและปรับแต่งแบ็กเอนด์สำหรับฟิวชันที่สร้างขึ้น

ไม่อนุญาตให้ผสานรวมเข้ากับการเรียกที่กำหนดเอง กล่าวคือ การเรียกที่กำหนดเองที่ตรงกับรูปแบบที่มี ผู้ผลิต/ผู้บริโภค และการเขียนใหม่เป็นการเรียกที่กำหนดเองใหม่ ในกรณีดังกล่าว คุณควรเปลี่ยนเป็นบัตรผ่าน Fusion ที่เหมาะสม

การปรับขนาดแนวนอน

การมีส่วนร่วมในการปรับขนาดแนวนอนครอบคลุมการเพิ่มประสิทธิภาพ HLO, การปรับปรุงโมเดลต้นทุน การอัปเดตไลบรารี และการแก้ไขโครงสร้างพื้นฐานต่างๆ เนื่องจาก การจำลองประสิทธิภาพที่เพิ่มขึ้นเป็นเรื่องยากและเรามีความต้องการ การกำหนดค่าแบบหลายโฮสต์ภายในอย่างจำกัด เราจึงยึดมั่นในเกณฑ์การยอมรับที่เข้มงวด

เราให้ความสำคัญกับการเปลี่ยนแปลงที่รบกวนน้อยที่สุดและมีความเสี่ยงต่ำ

สิ่งที่เรายอมรับโดยทั่วไปมีดังนี้

• การอัปเดตไลบรารีที่จัดการการสื่อสารระหว่าง GPU หรือระหว่างโฮสต์

• การอัปเดตตารางประสิทธิภาพสำหรับแพลตฟอร์มใหม่

โดยทั่วไปเราจะปฏิเสธเนื้อหาต่อไปนี้

• การเขียน HLO ใหม่หรือการเปลี่ยนแปลงรันไทม์ที่ปรับให้เหมาะกับโมเดลที่เฉพาะเจาะจง

• การเปลี่ยนแปลงโครงสร้างพื้นฐานที่ทำให้เกิดฟีเจอร์ใหม่ๆ หนี้ทางเทคนิค หรือการถดถอย

แบ็กเอนด์และการปรับอัตโนมัติ

ส่วนหลังสำหรับการดำเนินการที่ไม่ได้ซ้อนกัน เช่น การเรียกที่กำหนดเองและการผสาน ควรใช้ CodegenBackend อินเทอร์เฟซ

อินเทอร์เฟซนี้จำเป็นต่อการเลือกแบ็กเอนด์ที่เหมาะสมที่สุด เนื่องจากอินเทอร์เฟซนี้ มีวิธีการรวมพารามิเตอร์สำหรับคำสั่ง HLO ที่ระบุ ลงในพื้นที่ค้นหาของเครื่องมือเพิ่มประสิทธิภาพอัตโนมัติ

// Returns all supported configs for the given HLO instruction.
virtual absl::StatusOr<std::vector<std::unique_ptr<BackendConfig>>>
  GetSupportedConfigs(const HloInstruction& instr);

// Returns a default config for the given HLO instruction.
virtual absl::StatusOr<std::unique_ptr<BackendConfig>> GetDefaultConfig(
  const HloInstruction& instr);

รันไทม์

ผลลัพธ์สุดท้ายของไปป์ไลน์การคอมไพล์ XLA คือลำดับการเรียกใช้ฟังก์ชันย่อยที่สามารถ ทำให้เป็นอนุกรมได้

Thunk ประเภทใหม่ทั้งหมดควรเป็นแบบอนุกรมได้ กล่าวคือ GpuCompiler หรือ CpuCompiler ควรจะคอมไพล์โปรแกรม จัดลำดับอนุกรม เพื่อให้ภายหลัง โปรแกรมเรียกใช้ XLA สามารถโหลดและเรียกใช้โปรแกรมได้ ซึ่งหมายความว่าไม่ควรมีตัวชี้ไปยัง HloInstruction หรือไปยังส่วนอื่นๆ ของคอมไพเลอร์หรือ StreamExecutor

มาตรฐานโค้ด

• รูปแบบการเขียนโค้ด: เราใช้คู่มือรูปแบบการเขียนโค้ดของ Google โปรดดูคำแนะนำสำหรับ C/C++ และ Python โดยเฉพาะ โค้ดทั้งหมดที่ส่งต้องเป็นไปตามคู่มือรูปแบบเหล่านี้อย่างเคร่งครัด

• การเปลี่ยนแปลงที่กระชับ: เราปฏิบัติตาม แนวทางปฏิบัติด้านวิศวกรรมของ Google โดยเฉพาะอย่างยิ่ง โปรดปฏิบัติตามคำแนะนำในการเขียนการเปลี่ยนแปลงแบบกระชับ การทำเช่นนี้จะช่วยเพิ่มความเร็วในการผสานโค้ดของคุณได้อย่างมาก เนื่องจากช่วยปรับปรุงความสามารถในการตรวจสอบ และลดโอกาสที่จะเกิดผลข้างเคียงโดยไม่ตั้งใจจากการเปลี่ยนแปลง แม้ว่าคุณจะมีการเปลี่ยนแปลงครั้งใหญ่ แต่ก็มีกลยุทธ์มากมายในการแบ่งการเปลี่ยนแปลงออกเป็นส่วนๆ เพื่อให้ค่อยๆ เปลี่ยนแปลงทีละน้อย

• ความครอบคลุมของการทดสอบ: การเปลี่ยนแปลงทั้งหมดควรมีการทดสอบหน่วยที่เหมาะสม การทดสอบหน่วยไม่ควรขึ้นอยู่กับเวลาของฮาร์ดแวร์ที่เฉพาะเจาะจง (CPU, GPU ฯลฯ) และควรใช้การจำลองและข้อมูลจำลองอย่างอิสระเพื่อให้การทดสอบ เป็นแบบดีเทอร์มินิสติกและมุ่งเน้น การเปลี่ยนแปลงที่ต้องการขยายโค้ดที่มีอยู่ ซึ่งปัจจุบันทดสอบได้ยากควรทำการปรับปรุงที่เหมาะสมเพื่อ ความสามารถในการทดสอบ

  การเปลี่ยนแปลงทั้งหมดควรมีผลการเปรียบเทียบที่เหมาะสมในชื่อการเปลี่ยนแปลงเพื่อให้มั่นใจว่าผู้ใช้จะเข้าใจถึงประโยชน์ที่ได้รับอย่างชัดเจน

• หากไม่แน่ใจเกี่ยวกับรูปแบบภายในโค้ด คุณควร ตรวจสอบโค้ดที่มีอยู่ก่อนแล้วและพยายามทำตามรูปแบบที่มีอยู่ ใน OpenXLA

กระบวนการตรวจสอบ

การส่งทั้งหมด รวมถึงการส่งโดยสมาชิกในโปรเจ็กต์ ต้องได้รับการตรวจสอบ เรา ใช้คำขอพุลของ GitHub เพื่อวัตถุประสงค์นี้ โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้คำขอดึงข้อมูลในความช่วยเหลือของ GitHub

• โค้ดต้องเป็นไปตามมาตรฐานทั้งหมดที่ระบุไว้ข้างต้นก่อนรับการตรวจสอบ โดยการดำเนินการนี้ไม่ใช่ ทางเลือก และผู้ส่งต้องตรวจสอบว่าโค้ดเป็นไปตามข้อกำหนด ก่อนขอรับการตรวจสอบเพื่อให้มั่นใจว่าการเปลี่ยนแปลงจะได้รับการยอมรับอย่างทันท่วงที

• การทดสอบทั้งหมดต้องผ่าน หากพบว่าการทดสอบใช้งานไม่ได้และปัญหาไม่ได้ เกี่ยวข้องกับสภาพแวดล้อมในการสร้างหรือการเปลี่ยนแปลงของคุณ โปรดติดต่อ ผู้ดูแล

• พยายามหลีกเลี่ยงการขยายขอบเขตในระหว่างกระบวนการตรวจสอบ นี่คือ ความรับผิดชอบของทั้งผู้ส่งและผู้ตรวจสอบ หากการเปลี่ยนแปลงเริ่ม มีขนาดใหญ่เกินไป ให้พิจารณาแบ่งออกเป็นการเปลี่ยนแปลงหลายรายการ

• ก่อนที่จะผสานรวมการเปลี่ยนแปลง ระบบจะทำการทดสอบภายในโดยใช้โค้ดภายในของ Google และผู้จำหน่ายฮาร์ดแวร์รายอื่นๆ ซึ่งอาจเพิ่มขั้นตอนพิเศษ ในกระบวนการตรวจสอบหากการทดสอบภายในล้มเหลวและ CI สาธารณะ ของเราตรวจไม่พบ เจ้าหน้าที่ Google ที่ตรวจสอบการเปลี่ยนแปลงของคุณจะแจ้ง ความล้มเหลวในการทดสอบภายในและอธิบายสิ่งที่ต้องแก้ไข

คำถามที่พบบ่อย (FAQ)

"การเปลี่ยนแปลงโครงสร้างพื้นฐานนี้ไม่เกี่ยวข้องกับ PR ของฉัน ทำไมฉันจึงควรใช้วิธีนี้"

ทีม XLA ไม่มีทีมโครงสร้างพื้นฐานเฉพาะ ดังนั้นเราทุกคนจึงต้อง สร้างไลบรารีตัวช่วยและหลีกเลี่ยงหนี้ทางเทคนิค เราถือว่าการดำเนินการนี้เป็นส่วนหนึ่งของการเปลี่ยนแปลง XLA ตามปกติ และทุกคนควรมีส่วนร่วม โดยทั่วไปเราจะสร้างโครงสร้างพื้นฐานตามความจำเป็นเมื่อเขียนโค้ด

ผู้ตรวจสอบ XLA อาจขอให้คุณสร้างโครงสร้างพื้นฐานบางอย่าง (หรือทำการเปลี่ยนแปลงขนาดใหญ่ใน PR) พร้อมกับ PR ที่คุณเขียน คำขอนี้อาจดูเหมือน ไม่จำเป็นหรือไม่ได้เกี่ยวข้องกับการเปลี่ยนแปลงที่คุณพยายามทำ สาเหตุอาจเกิดจากความคาดหวังที่ไม่ตรงกันระหว่างคุณกับผู้ตรวจสอบเกี่ยวกับปริมาณโครงสร้างพื้นฐานที่คุณต้องสร้าง

ความคาดหวังไม่ตรงกันก็ไม่เป็นไร ซึ่งเป็นเรื่องปกติเมื่อคุณเพิ่งเริ่มโปรเจ็กต์ (และบางครั้งก็เกิดขึ้นกับเราซึ่งเป็นผู้เชี่ยวชาญด้วย) โปรเจ็กต์ที่คุณเคยทำในอดีตอาจมีความคาดหวังที่แตกต่างกัน ซึ่งก็ถือเป็นเรื่องปกติ ซึ่งไม่ได้หมายความว่าโปรเจ็กต์ใดโปรเจ็กต์หนึ่งมีแนวทางที่ไม่ถูกต้อง แต่เป็นเพียงความแตกต่างเท่านั้น เราขอเชิญคุณใช้คำขอเกี่ยวกับโครงสร้างพื้นฐานพร้อมกับความคิดเห็นในการตรวจสอบอื่นๆ ทั้งหมดเป็นโอกาสในการเรียนรู้สิ่งที่เราคาดหวังในโปรเจ็กต์นี้

"ฉันจะพูดถึงความคิดเห็นของคุณในข่าวประชาสัมพันธ์ในอนาคตได้ไหม"

คำถามที่พบบ่อยเกี่ยวกับการขอโครงสร้างพื้นฐาน (หรือคำขอขนาดใหญ่อื่นๆ) ในคำขอส่งรวมคือการเปลี่ยนแปลงต้องทำในคำขอส่งรวมเดิมหรือไม่ หรือจะทำเป็นคำขอส่งรวมติดตามผลในอนาคตได้หรือไม่

โดยทั่วไป XLA ไม่อนุญาตให้ผู้เขียน PR ตอบความคิดเห็นในการตรวจสอบด้วย PR ติดตาม เมื่อผู้ตรวจสอบตัดสินใจว่าต้องแก้ไขบางอย่างใน PR ที่ระบุ โดยทั่วไปเราคาดหวังให้ผู้เขียนแก้ไขใน PR นั้น แม้ว่าสิ่งที่ขอให้แก้ไขจะเป็นการเปลี่ยนแปลงครั้งใหญ่ก็ตาม มาตรฐานนี้มีผลบังคับใช้ภายนอกและภายใน Google

XLA ใช้แนวทางนี้ด้วยเหตุผลบางประการ

• ความเชื่อใจ: การได้รับความเชื่อใจจากผู้ตรวจสอบเป็นองค์ประกอบสำคัญ ในโปรเจ็กต์โอเพนซอร์ส ผู้มีส่วนร่วมจะปรากฏหรือหายไปได้ตามต้องการ หลังจากที่เรา อนุมัติ PR แล้ว ผู้ตรวจสอบจะไม่มีวิธีตรวจสอบว่าการติดตามผลตามที่สัญญาไว้ จะเกิดขึ้นจริง

• ผลกระทบต่อผู้พัฒนาคนอื่นๆ: หากคุณส่งคำขอให้รวมการเปลี่ยนแปลงที่เกี่ยวข้องกับส่วนใดส่วนหนึ่งของ XLA มีโอกาสสูงที่คนอื่นๆ จะดูส่วนเดียวกัน หากเรายอมรับหนี้ทางเทคนิคใน PR ของคุณ ทุกคนที่ดูไฟล์นี้จะได้รับผลกระทบจากหนี้ดังกล่าวจนกว่าจะมีการส่งการติดตามผล

• แบนด์วิดท์ของผู้ตรวจสอบ: การเลื่อนการเปลี่ยนแปลงไปเป็นการติดตามผลจะทำให้ผู้ตรวจสอบที่ทำงานหนักอยู่แล้วต้องเสียค่าใช้จ่ายหลายอย่าง ผู้ตรวจสอบอาจลืม ว่า PR แรกเกี่ยวกับอะไรในขณะที่รอการติดตามผล ซึ่งจะทำให้การตรวจสอบครั้งถัดไป ยากขึ้น นอกจากนี้ ผู้ตรวจสอบจะต้องติดตามผลการดำเนินการที่คาดไว้เพื่อให้มั่นใจว่าการดำเนินการดังกล่าวเกิดขึ้นจริง หากทำการเปลี่ยนแปลง ให้ตั้งฉากกับ PR เดิมอย่างแท้จริง เพื่อให้ผู้ตรวจสอบคนอื่นๆ ตรวจสอบได้ แบนด์วิดท์ก็จะไม่ใช่ปัญหามากนัก จากประสบการณ์ของเรา กรณีเช่นนี้เกิดขึ้นไม่บ่อยนัก