ตอนนี้เป็นช่วงเวลาที่ดีในการมีส่วนร่วมกับ Free Threading Python
ที่ PyCon US 2025 ผมอยากสรุปแบบสั้น ๆ ถึงสิ่งที่ได้ทำความเข้าใจมาเกี่ยวกับ Free Threading Python จนถึงตอนนี้ รวมถึงสรุปแนวทางในการมีส่วนร่วมด้วย
Free Threading Python คืออะไร?
Free Threading Python เป็นโปรเจ็กต์ที่มีเป้าหมายเพื่อนำ GIL (Global Interpreter Lock) ของ Python ออก เพื่อปรับปรุงประสิทธิภาพในสภาพแวดล้อมแบบมัลติเธรด โปรเจ็กต์นี้เริ่มต้นขึ้นเพื่อปรับปรุงประสิทธิภาพการทำงานแบบมัลติเธรดของ Python และเพื่อให้ได้ประสิทธิภาพที่ดีกว่าในงานแบบ CPU-bound
ตอนนี้ยังอยู่ในขั้นทดลอง และต้องคอมไพล์ใหม่เพื่อติดตั้ง หรือไม่ก็ติดตั้งผ่าน uv
สถานการณ์ปัจจุบัน
ผมเองก็ยังแค่ลองทดสอบอยู่ แต่ได้ยินมาว่าไลบรารี Python ล้วนส่วนใหญ่ไม่มีปัญหาในการใช้งาน อย่างไรก็ตาม ไลบรารีที่คนส่วนใหญ่นิยมใช้กันมักเรียกใช้ไลบรารีที่เขียนด้วย C/C++ หรือทำเป็นส่วนขยายโดยตรง เพราะเหตุผลด้านประสิทธิภาพหรือการติดตั้งใช้งาน ดังนั้นหากจะใช้ไลบรารีเหล่านี้กับ Free Threading Python ก็จำเป็นต้องใช้วิธีต่าง ๆ เข้ามาช่วย
กรณีใช้ extension module
ส่วนใหญ่จะใช้วิธีต่อไปนี้ และมี คู่มือการพอร์ต ให้ดู
- C API
- Cython
- PyBind11
- nanonbind
- PyO3
- f2py
CFFI ยังไม่รองรับ แต่สามารถใช้งานได้ผ่าน fork ของ Quansight
มี issue ที่ระบุว่าจะไม่รองรับ อยู่ แต่ก็พอเข้าใจการตัดสินใจนี้ได้ เพราะ CFFI ส่วนใหญ่ถูกใช้เพื่อการเชื่อมต่ออินเทอร์เฟซอยู่แล้ว หากใช้ CFFI ที่ถูก fork มาก็สามารถใช้ Free Threading Python ได้ แต่คงไม่ได้เป็นการรองรับในระดับละเอียดนัก จึงน่าจะทำให้ประสิทธิภาพลดลง
วิธีมีส่วนร่วม
ตั้งแต่ตรงนี้เป็นต้นไปอาจเหมือนกระโดดลงหลุมลึก แต่ตอนที่ผมเข้าร่วมสปรินต์ ทุกคนล้วนมองในเชิงบวก เลยคิดว่าตอนนี้ยังเป็นช่วงเวลาที่ดีในการมีส่วนร่วม วิธีมีส่วนร่วมมีดังนี้
อ้างอิงข้อมูลต่อไปนี้เพื่อตรวจสอบว่าเข้ากันได้ดีกับ free-threading-python หรือไม่
- Free-threaded Python Library Compatibility Checker
- 🧵 Free-Threaded Wheels
- Compatibility Status Tracking#
ทดสอบแล้วค่อยเปิด issue
ให้ติดตั้ง 3.13 free-threading python ก่อน จากนั้นติดตั้งไลบรารีแล้วรันทดสอบ
ถ้าเป็นไปได้จะลองเวอร์ชัน 3.14t ด้วยก็ดี แต่เพราะยังเป็นเบต้าอยู่ ตอนนี้แนะนำให้เริ่มจากเวอร์ชัน 3.13 ก่อน
พอร์ตแล้วส่ง PR
ตั้งแต่ตรงนี้จะยากขึ้นเล็กน้อย ต้องมีความเข้าใจพอสมควรเกี่ยวกับมัลติเธรด, system call หลายประเภท รวมถึงภายในของ C/C++ และ Python
สิ่งที่ยากที่สุดคือไลบรารีจำนวนมากมักมี dependency ต่อกัน ใช้ไลบรารีตัวอื่นอยู่ และถ้าไลบรารีนั้นยังไม่รองรับ ก็ต้องเริ่มจากตรงนั้นก่อน
ตอนที่ผมเข้าร่วมสปรินต์ ผมเองก็เพิ่งทำได้แค่สำรวจภาพรวม แต่ลักษณะจะประมาณนี้
- fastapi -> uvicorn -> uvloop, cryptography, pycares
เขียนบทความเกี่ยวกับวิธีมีส่วนร่วม
ซึ่งตอนนี้ผมก็กำลังทำอยู่ แม้อาจยังไม่สมบูรณ์นัก งั้นก็ลองเขียนบทความแล้วโพสต์ตามที่ต่าง ๆ กันเถอะ
เขียนวิธีใช้งาน free-threading-python
เพราะบทความภาษาเกาหลีมีไม่เพียงพอ จึงควรทำ performance test เขียนวิธีใช้งาน สรุปข้อมูล แล้วเผยแพร่เป็นบทความ
ทำไมจึงควรมีส่วนร่วมตอนนี้
ผมอยู่ในระบบนิเวศโอเพนซอร์สมาราว ๆ เกิน 25 ปีแล้ว แม้ผมจะไม่ใช่ผู้มีส่วนร่วมโอเพนซอร์สที่ยิ่งใหญ่อะไร แต่คนรู้จักของผมมีหลายคนที่มีส่วนร่วมอย่างมาก และยังมี CPython Core Developer อยู่ถึงสองคน รวมถึงคนอื่น ๆ อีกมาก ด้วยเหตุนี้ เวลาคุยกับพวกเขา ผมจึงมีลางสังหรณ์บางอย่าง
ช่วงที่ยังไม่มีอะไรเลย หรือช่วงที่เกิดการเปลี่ยนแปลงครั้งใหญ่ เป็นช่วงที่เหมาะกับการเข้าไปมีส่วนร่วม ตัวอย่างเช่น คุณจางฮเยซึ่งมีส่วนร่วมตั้งแต่ยุคแรกของ Python นอกจากทำอย่างอื่นอีกมาก ก็ยังทำเรื่อง unicode และ Korean codec ด้วย ตอนนั้นยังไม่มีอะไรเลย และผู้มีส่วนร่วมหลักก็คงไม่รู้เรื่อง Korean codec มากนัก จึงน่าจะเป็นจุดที่เข้าถึงได้ค่อนข้างง่าย แล้วการเปลี่ยนแปลงใหญ่อีกครั้งก็คือตอนย้ายไป Python 3 หลังจากนั้นก็คือฝั่ง asyncio ซึ่งผมจำคุณคิมจุนกีได้ดี และก็ยังมีอีกหลายคน ตอนนี้ฟีเจอร์ใหม่อย่าง free-threading ก็มาแล้ว ผมคิดว่าตอนนี้แหละคือช่วงเวลาที่ดีที่สุดในการมีส่วนร่วม
ในภาษาอื่น ๆ มักเป็นการเปลี่ยนแปลงที่ตัดสินใจโดยบริษัท หรืออยู่ในเฟรมเวิร์กที่บริษัทใหญ่ดูแลอยู่แล้ว จึงไม่ง่ายนัก แน่นอนว่า Python เองก็ไม่ได้เข้าถึงง่ายมากเช่นกัน แต่เพราะมีไลบรารีและเฟรมเวิร์กอยู่นับไม่ถ้วน และตอนนี้สามารถพอร์ตได้ทีละตัว อีกทั้งยังต้องใช้กำลังคนจำนวนมาก นี่จึงเป็นช่วงเวลานั้นพอดี
12 ความคิดเห็น
เหตุผลสำคัญที่ Python ได้รับความนิยมก็เพราะแต่เดิมไม่จำเป็นต้องกังวลเรื่องมัลติเธรดถึงขนาดนี้ด้วย แต่ถ้าต้องคำนึงถึงเรื่องพวกนั้นด้วย ภาษานี้ก็คงจะกลายเป็นภาษาที่คนทั่วไปใช้งานได้ไม่ง่ายนัก
ตอนนี้ยังเป็นฟีเจอร์แบบเลือกใช้ และมีโอกาสสูงที่การทำงานหลายเธรดจะยังคงเป็นตัวเลือกต่อไป (เช่น ต้องเปิดออปชัน หรือแยกติดตั้งต่างหาก เป็นต้น)
ผมเองก็ไม่ค่อยใช้ Type และคิดว่าน่าจะใช้ free-threading บ้างเพราะมีประเด็นด้านประสิทธิภาพ แต่คงจะใช้ในขอบเขตที่จำกัดมาก
เราไม่ได้มองว่านี่เป็นสิ่งที่เลือกทำหรือไม่ทำก็ได้ หาก PEP 779 ได้รับการอนุมัติ เป้าหมายในอนาคตคือเปลี่ยนอิมพลีเมนเทชันมาตรฐานให้เป็นแบบ free-threaded
ตั้งใจประมาณว่า น่าจะใช้ได้แบบไม่ต้องคิดมากเหมือน
typeไหมนะ ฮึฮึfree threading python นี่ดูไม่ใช่เรื่องง่ายเอาเสียเลยจริงๆ ให้ความรู้สึกเหมือนกำลังเปิดกล่องแพนโดรา มีความเป็นไปได้ที่บั๊กด้านการซิงโครไนซ์สารพัดแบบที่ซ่อนอยู่จนถึงตอนนี้จะปะทุขึ้นมา แถมยังอาจโผล่มาตอนรันไทม์แบบนานๆ ทีอีกต่างหาก ปัญหาที่เคยปวดหัวเวลา开发แบบมัลติเธรดอาจเริ่มเกิดขึ้นกับ Python อย่างจริงจังก็ได้ แค่ดูตระกูล C ก็พอ ส่วนที่ใช้ฟังก์ชันที่ไม่ thread-safe ก็น่าจะเกิดปัญหาทันทีเลย
คงจะดีถ้ามี Agent ที่ช่วยพอร์ตและทดสอบให้อัตโนมัติ!
เพราะเป็นปัญหาเรื่อง multi-thread เลยคงไม่ง่ายนัก
ตอนนี้สามารถติดตั้งได้ง่ายแม้ผ่าน deadsnakes หรือ installer อย่างเป็นทางการของ Windows และ macOS โดยไม่ต้องคอมไพล์เอง!
มีคำผิดเยอะนะครับ TT ที่นี่ยังอัปเดตไม่ได้ เลยไปอัปเดตไว้ในบล็อกแล้วครับ
สวัสดีครับ ผมเห็นโพสต์นี้จากคำแนะนำของ Google เลยติดต่อมาครับ ผมทำงานพัฒนา Python ในต่างประเทศมา 5 ปี (ทำงานพัฒนาทั่วไป 13 ปี) ตอนนี้กำลังพักอยู่ที่เกาหลีชั่วคราวครับ ผมอยากมีส่วนร่วมมากครับ ไม่ทราบว่าจะขออีเมลติดต่อได้ไหมครับ? ผมอยากติดต่อไปและเรียนรู้เกี่ยวกับเรื่องนี้ครับ
อีเมลของฉันคือ josephroh@naver.com ขอบคุณครับ
ส่งอีเมลไปแล้ว ขอบคุณครับ