การเตรียมการทดลอง Free-threaded CPython เสร็จสมบูรณ์

 (labs.quansight.org)
3 คะแนน โดย GN⁺ 2024-07-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Free-threaded CPython เป็นการเปลี่ยนแปลงครั้งใหญ่ที่ทำให้สามารถรันหลายเธรดแบบขนานภายในอินเทอร์พรีเตอร์เดียวกันได้
  • มีให้ใช้งานเป็นฟีเจอร์ทดลองใน CPython 3.13
  • ขอบคุณ PEP 703 ทำให้สามารถรันโดยปิดการใช้งาน GIL ได้
  • มีความสำคัญต่อการปรับปรุงประสิทธิภาพ โดยเฉพาะประสิทธิภาพแบบมัลติเธรด
  • ช่วยให้ใช้หลายคอร์ของ CPU ได้อย่างมีประสิทธิภาพ

น่าตื่นเต้นก็จริง แต่มีปัญหาอะไรบ้าง?

  • การทำ free-threading ในตัว CPython เองต้องใช้ความพยายามอย่างมาก
  • มีปัญหาหลักสองอย่าง: ความปลอดภัยของเธรดและความเข้ากันได้ของ ABI
    • ความปลอดภัยของเธรด: โค้ด Python ล้วนสามารถทำงานได้โดยไม่ต้องแก้ไข แต่โค้ดที่เขียนด้วยภาษาอื่นหรือโค้ดที่ใช้ CPython C API อาจไม่เป็นเช่นนั้น
    • ความเข้ากันได้ของ ABI: อินเทอร์พรีเตอร์แบบ free-threaded ใช้ ABI ที่ต่างออกไป ดังนั้นแต่ละแพ็กเกจที่มี extension module จะต้องสร้าง wheel เพิ่มเติม
  • ปัญหาด้านความปลอดภัยของเธรดนั้นเข้าใจ ปรับปรุง และทดสอบได้ยาก
  • ตัวอย่าง: ความล้มเหลวที่เกิดขึ้นเป็นครั้งคราวใน numpy#26690, pywavelets#758 เป็นต้น

แผนต่อจากนี้และงานของทีม

  • ต้องใช้เวลาอีกหลายปีกว่า free-threaded CPython จะกลายเป็นค่าเริ่มต้น
  • หวังว่าใน Python 3.13 จะมีหลายโปรเจ็กต์ทำงานด้านความเข้ากันได้และปล่อย cp313t wheel บน PyPI
  • ทีมได้เริ่มทำงานจากส่วนล่างของสแตก PyData มาหลายเดือนแล้ว
  • สำหรับแต่ละแพ็กเกจ ใช้แนวทางที่คล้ายกันดังนี้:
    1. เพิ่มงาน CI ตัวแรก
    2. แก้ปัญหาความปลอดภัยของเธรดและปัญหาสถานะแบบแชร์/โกลบอล
    3. เพิ่มการรองรับ free-threaded ให้กับงาน CI สำหรับการสร้าง wheel
    4. ทำ stress test ในเครื่องและติดตามงาน CI
    5. ระบุว่า extension module สามารถรันได้โดยไม่มี GIL
    6. ย้ายไปยังแพ็กเกจถัดไป

สรุปของ GN⁺

  • Free-threaded CPython เป็นการเปลี่ยนแปลงสำคัญที่สามารถยกระดับประสิทธิภาพแบบมัลติเธรดได้อย่างมาก
  • การแก้ปัญหาความปลอดภัยของเธรดและความเข้ากันได้ของ ABI คือความท้าทายหลัก
  • หวังว่าใน Python 3.13 จะมีหลายโปรเจ็กต์ทำงานด้านความเข้ากันได้และสามารถทดลองใช้งานได้
  • แพ็กเกจหลักอย่าง PyTorch และแพ็กเกจขนาดเล็กอีกจำนวนมากจำเป็นต้องรองรับการเปลี่ยนแปลงนี้
  • โปรเจ็กต์ที่เกี่ยวข้องได้แก่ PyO3 และ PyTorch

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

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

 
GN⁺ 2024-07-13
ความเห็นบน Hacker News

  • การนำ GIL ออกจาก Python เปิดโอกาสให้องค์กรและโปรเจ็กต์จำนวนมากเพิ่มประสิทธิภาพได้อย่างมากโดยแทบไม่ต้องออกแรงเพิ่ม

    • หากไลบรารีรุ่นเก่าไม่ปรับตัวให้ทันกับการเปลี่ยนแปลงนี้ โปรเจ็กต์ใหม่ก็อาจเข้ามาชิงส่วนแบ่งตลาดได้
    • จะสามารถหลีกเลี่ยงความซับซ้อนและบั๊กของ multiprocessing แล้วใช้ threads แบบเรียบง่ายเพื่อดึงทุกคอร์ของเครื่องขนาดใหญ่มาใช้งานได้

  • มีการแชร์ประสบการณ์การติดตั้งและรัน Python ที่ถอด GIL ออกแล้วบน macOS

    • เขียนสคริปต์สั้น ๆ เพื่ออธิบายขั้นตอนการติดตั้งและความแตกต่างต่าง ๆ
    • ลิงก์

  • ผู้ใช้ที่ชอบความเขียนง่ายและตรรกะของ Python หวังว่าแนวทางแบบถอด GIL จะยังคล้ายกับวิธีเขียน Python แบบเดิม

    • ระบุว่าตนไม่ได้ลงลึกกับ multithreading มากนักเพราะมันยาก

  • มีการสรุปความคืบหน้าของ Python 3

    • [x] Async
    • [x] Optional static typing
    • [x] Threading
    • [ ] JIT
    • [ ] Efficient dependency management

  • มีการย้อนนึกว่าราวปี 2007 การประมวลผลแบบขนานกลายเป็นสิ่งจำเป็น

    • ระบุว่า Rust กำลังได้เปรียบในด้านความเร็วและการประมวลผลแบบขนาน

  • อธิบายว่าใน PEP703 หลังถอด GIL แล้ว การทำงาน append ของลิสต์ยังคงรักษาความปลอดภัยต่อเธรดได้อย่างไร

    • มีการเพิ่มล็อกแยกตามลิสต์
    • ระบุว่าการเพิ่มค่าจำนวนเต็มอย่างง่ายในปัจจุบันปลอดภัยต่อเธรดเพราะ GIL

  • คาดหวังว่าการถอด GIL จะเปลี่ยนธรรมชาติของการฝึกและการอนุมานของ ML อย่างไร

    • อาจลดความซับซ้อนของการส่งผ่านหน่วยความจำและการประสานงานระหว่างโปรเซสได้
    • คาดหวังว่าไลบรารีอย่าง PyTorch จะได้รับการปรับแต่งให้เหมาะสม

  • กังวลว่านักพัฒนาที่ไม่เคยจัดการ multithreading จริง ๆ มาก่อน อาจนำบั๊กแบบละเอียดอ่อนรูปแบบใหม่เข้ามา

  • ตั้งคำถามว่าประสิทธิภาพแบบ single-thread ที่ลดลงนั้นร้ายแรงหรือไม่

    • หา benchmark ไม่พบ และมีเพียงคำยืนยันกว้าง ๆ ให้สบายใจ

  • แสดงความสงสัยเกี่ยวกับวิธีทำงานร่วมกับ async

    • มีเส้นแบ่งตามธรรมชาติระหว่างโค้ดแบบ I/O-bound กับ CPU-bound
    • อยากเห็นโมเดลที่ยืดหยุ่นกว่านี้
    • สงสัยว่า JIT จะเป็นไปได้หรือไม่เมื่อทำ "gather" ใน coroutine ที่เป็น CPU-bound
    • คิดว่าโมเดลการเขียนโปรแกรมที่ยืดหยุ่นและสลับได้รวดเร็วด้วยอินเทอร์เฟซที่คล้ายกันจะยอดเยี่ยมมาก