ความคืบหน้าของการพัฒนา No-GIL ใน CPython

 (lwn.net)
1 คะแนน โดย GN⁺ 2023-10-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • คณะกรรมการกำกับดูแล Python ประกาศแผนที่จะทำให้ Global Interpreter Lock (GIL) เป็นตัวเลือกได้ใน Python รุ่นถัดไปในอนาคต
  • PEP 703 ซึ่งยังเป็นข้อเสนอที่อยู่ระหว่างการหารือ กำลังอยู่ในขั้นตอนสรุปรายละเอียด
  • Python เวอร์ชัน no-GIL คาดว่าจะต้องแก้ปัญหาที่ยากที่สุดบางอย่างในวิทยาการคอมพิวเตอร์ โดยเฉพาะปัญหาเรื่องการตั้งชื่อ
  • Sam Gross ผู้เขียน PEP 703 ได้หารือถึงปฏิสัมพันธ์ระหว่างข้อเสนอนี้กับ stable ABI ของ CPython
  • stable ABI ถูกใช้กับส่วนขยายเพื่อให้สามารถใช้ไบนารี wheel ที่เข้ากันได้กับ CPython หลายเวอร์ชัน
  • ข้อเสนอนี้จินตนาการถึง CPython เวอร์ชันเดียวที่ไม่มี GIL แต่ในระหว่างทางจะมี interpreter build ที่สามารถใช้ทดสอบการทำงานแบบ no-GIL ได้
  • ส่วนขยายที่สร้างขึ้นสำหรับ stable ABI จะไม่เข้ากันได้กับ no-GIL CPython 3.13 แต่ Gross เสนอให้ปรับเปลี่ยนส่วนขยายหลังจากเวอร์ชันนั้นเพื่อให้ทำงานได้กับ CPython build สองประเภท
  • การหารือเรื่องการตั้งชื่อของ CPython เวอร์ชัน no-GIL ถูกแยกออกไปเป็นอีกเธรดหนึ่ง
  • คณะกรรมการกำกับดูแลเห็นพ้องกันว่าจะหลีกเลี่ยงการใช้ชื่อ "nogil" เพื่ออธิบาย build และเสนอ "free-threading" เป็นทางเลือก
  • การอนุมัติขั้นสุดท้ายของ PEP 703 ยังถูกชะลอไว้ และคณะกรรมการกำกับดูแลกำลังทำงานเพื่อทำให้เกณฑ์การอนุมัติชัดเจนขึ้น
  • คาดว่า CPython เวอร์ชัน no-GIL จะส่งผลกระทบสำคัญต่อการพัฒนา CPython และระบบนิเวศของมันไปอีกอย่างน้อย 5 ปี

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-10-22
ความคิดเห็นจาก Hacker News
  • การพูดคุยเกี่ยวกับความคืบหน้าของ No-GIL CPython
  • มีความเห็นว่าความขนานแบบชัดเจนควรมีความสำคัญมากขึ้นในการประมวลผลสมัยใหม่ และ Python ควรปรับตัวให้เข้ากับแนวโน้มนี้
  • ความกังวลว่าเมื่อเอา GIL ออกแล้ว อาจเกิด data race และการทำงานที่ผิดพลาดในโค้ด Python แบบมัลติเธรด
  • คำถามเกี่ยวกับความเป็นไปได้ของ static analyzer ที่สามารถระบุปัญหาที่อาจเกิดขึ้นในโปรแกรม Python เดิมได้หลังจากนำ GIL ออก
  • ผู้แสดงความคิดเห็นบางคนเปรียบเทียบวิวัฒนาการของ Python กับ OCaml และสงสัยว่าทั้งสองโครงการมีความคล้ายคลึงกันหรือไม่
  • การถกเถียงเกี่ยวกับจุดเน้นในปัจจุบันของ Python แบบไม่มี GIL โดยบางคนมองว่าควรให้ความสำคัญกับการปรับปรุงประสิทธิภาพแบบ single-thread มากกว่ามัลติเธรดจริง
  • ผู้แสดงความคิดเห็นบางคนเสนอว่าควรคง GIL ไว้ แต่เพิ่ม Workers แบบเดียวกับ JavaScript โดยให้แต่ละ worker thread เป็น VM ที่แยกออกจากกันและมี GIL ของตัวเอง
  • ยังมีการพูดถึงการเปลี่ยนผ่านที่ยาวนานและยากลำบากจาก Python 2 ไป Python 3 โดยบางคนเสนอว่าชุมชน Python น่าจะใช้โอกาสนั้นเพื่อเปลี่ยนแปลงภายใน interpreter ให้มากกว่านี้
  • มีการแสดงความสงสัยเกี่ยวกับแอปพลิเคชันและบริการที่อาจได้รับประโยชน์จาก No-GIL Python รวมถึงสิ่งที่นักพัฒนาคาดหวังจากการพัฒนานี้