ทบทวนปีแรกของ Free-Threaded Python

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

---

ภาพรวม

สัปดาห์ที่ผ่านมา CPython 3.14.0b1 ได้ถูกเผยแพร่ และสัปดาห์นี้ PyCon 2025 ก็เริ่มต้นขึ้นที่พิตต์สเบิร์ก
ทั้งสองเหตุการณ์นี้ถือเป็นหมุดหมายสำคัญในแง่ของการเผยแพร่และการทำให้ Free-threaded Python มีเสถียรภาพ
บทความนี้ทบทวนเส้นทางตลอดหนึ่งปีที่ผ่านมา และอธิบายว่าทีม Quansight มีบทบาทสำคัญอย่างไรในการนำบิลด์แบบ free-threaded ไปทดลองใช้กับเวิร์กโฟลว์โปรดักชันจริงที่มี dependency ซับซ้อน

ความหมายและความจำเป็นของ Free-Threaded Python

• การรองรับ Free-threaded Python ทำให้สามารถใช้ทรัพยากรการประมวลผลทั้งหมดของฮาร์ดแวร์สมัยใหม่ที่มี CPU และ GPU แบบมัลติคอร์เป็นเรื่องปกติได้
• ในแนวทางเดิมที่ใช้ GIL (Global Interpreter Lock) หากต้องการใช้ประโยชน์จากอัลกอริทึมแบบขนานอย่างเต็มที่ จำเป็นต้องมีวิธีอ้อมและการปรับแต่งเพิ่มเติม
• โดยทั่วไปมักใช้ multiprocessing มากกว่าโมดูล threading แต่แนวทางนี้มีต้นทุนในการสร้างโปรเซสสูง และการคัดลอกข้อมูลก็ไม่มีประสิทธิภาพ
• หากแพ็กเกจ Python มี native code อยู่ด้วย บิลด์แบบ free-threaded จะไม่เข้ากันได้ทันที ดังนั้นจึงจำเป็นต้องตรวจสอบโค้ดเพื่อรับประกันความปลอดภัยของเธรด
• การปลด GIL ต้องอาศัยการเปลี่ยนแปลงเชิงโครงสร้างอย่างลึกในอินเทอร์พรีเตอร์ CPython และยังเป็นจุดที่ทำให้เห็นปัญหาเชิงโครงสร้างของแพ็กเกจเดิมด้วย

ความสำเร็จสำคัญ

• ร่วมกับ ทีม Python runtime ของ Meta ได้มีส่วนสนับสนุนการรองรับ Free-threaded Python ให้กับแพ็กเกจและโปรเจ็กต์หลายรายการดังนี้
  • เครื่องมือด้านแพ็กเกจจิงและเวิร์กโฟลว์ เช่น meson, meson-python, setup-python GitHub Actions, packaging, pip, setuptools
  • เครื่องมือสร้าง binding เช่น Cython, pybind11, f2py, PyO3
  • แพ็กเกจหลักในระบบนิเวศ PyData เช่น NumPy, SciPy, PyArrow, Matplotlib, pandas, scikit-learn, scikit-image
  • dependency สำคัญที่มียอดดาวน์โหลดสูงบน PyPI เช่น Pillow, PyYAML, yarl, multidict, frozenlist
• แพ็กเกจยอดนิยมที่ยังไม่รองรับ (เช่น CFFI, cryptography, PyNaCl, aiohttp, SQLAlchemy, grpcio) และไลบรารีแมชชีนเลิร์นนิง (เช่น safetensors, tokenizers) ก็กำลังอยู่ระหว่างดำเนินการอย่างต่อเนื่อง
• นักพัฒนาหลักของ CPython ในทีม Quansight ได้นำการปรับปรุงต่อไปนี้เข้าสู่เวอร์ชัน 3.14
  • โมดูล warnings ทำงานแบบปลอดภัยต่อเธรดโดยค่าเริ่มต้นในบิลด์ free-threaded
  • ปรับปรุงปัญหาความปลอดภัยของเธรดที่รุนแรงใน asyncio และเพิ่มความสามารถในการขยายแบบขนาน
  • ปรับปรุงความปลอดภัยของเธรดครั้งใหญ่ใน ctypes module
  • เพิ่มประสิทธิภาพของ garbage collector สำหรับ free-threaded
  • ปรับแต่งสคีม deferred reference counting และ adaptive specializing interpreter
  • แก้บั๊กจำนวนมากและเสริมความปลอดภัยของเธรดอย่างต่อเนื่อง
• ยังได้จัดทำคู่มือแบบครอบคลุม1 สำหรับการรองรับ Free-threaded Python เพื่อให้เป็นเอกสารอ้างอิงที่นำไปใช้ได้จริงกับแพ็กเกจอื่น ๆ ในอนาคต

สถานะของระบบนิเวศ Free-Threaded Python

• เมื่อหนึ่งปีก่อน (ตอนที่ 3.13.0b1 ออก) การติดตั้งแพ็กเกจ Python ส่วนใหญ่บนบิลด์ free-threaded พังเกือบทั้งหมด
• สาเหตุของการบิลด์ล้มเหลวไม่ใช่ปัญหาพื้นฐานโดยตรง แต่เกิดจากตัวเลือกค่าเริ่มต้นที่ไม่รองรับหรือสมมติฐานเล็ก ๆ ที่ใช้ไม่ได้อีกต่อไป
• ตลอดปีที่ผ่านมา มีการร่วมมือกับชุมชนเพื่อแก้ปัญหาจำนวนมาก โดยเฉพาะการที่ Cython 3.1.0 รองรับอย่างเป็นทางการถือเป็นจุดเปลี่ยนสำคัญ
• ยังมีแพ็กเกจที่มีโค้ดคอมไพล์อยู่แต่ยังไม่ปล่อย wheel แบบ free-threaded
  สามารถดูความคืบหน้าของแพ็กเกจเหล่านี้ได้จากตารางติดตามแบบ manual และอัตโนมัติ2

ความท้าทายในปัจจุบัน

• ปัจจุบันบิลด์ Free-threaded Python อยู่ในช่วงที่ต้องการการทดลองใช้งานและฟีดแบ็กจากเวิร์กโฟลว์จริง
• มีโอกาสปรับปรุงประสิทธิภาพอย่างมาก โดยเฉพาะในเวิร์กโฟลว์ที่มีต้นทุนจากการใช้multiprocessingสูง แต่ก็จำเป็นต้องมีการตรวจสอบความเสถียรของเธรดอย่างละเอียดในแต่ละแพ็กเกจ
• ไลบรารีจำนวนมากมีการให้บริการโครงสร้างข้อมูลแบบ mutable แต่ยังมีทั้งเอกสารด้านความปลอดภัยของเธรดและการรับประกันความปลอดภัยจริงที่ไม่เพียงพอ
• หากแพ็กเกจมีขนาดใหญ่และมี legacy มาก มักเกิดปัญหาว่ามีคนที่เข้าใจโค้ดทั้งหมดไม่เพียงพอ ทำให้การรองรับล่าช้า
• ในระดับชุมชน ยังจำเป็นต้องมีความพยายามเพื่อความยั่งยืนของการดูแลแพ็กเกจแกนหลัก

วิธีมีส่วนร่วม

• สามารถอ้างอิง คู่มือการมีส่วนร่วม ในคู่มือทางการได้
• ประเด็นของทั้งระบบนิเวศและเอกสารความเข้ากันได้หลัก ถูกติดตามและดูแลในรีโพซิทอรี free-threaded-compatibility5
• สามารถเข้าร่วมการสนทนาและมีส่วนร่วมได้ใน community Discord6 ที่ดูแลโดย Quansight-Labs

กำหนดการนำเสนอใน PyCon

• ผู้เขียนบทความและเพื่อนร่วมทีม Lysandros Nikolaou มีกำหนดจะบรรยายในงาน PyCon 2025
• มีแผนจะแชร์กรณีศึกษาการพอร์ตและแนวปฏิบัติที่ได้จากประสบการณ์จริง พร้อมทั้งจะมีวิดีโอบันทึกบน YouTube ด้วย
• พวกเขาเชื่อว่าบิลด์แบบ free-threaded คืออนาคตของภาษา Python และรู้สึกตื่นเต้นอย่างมากที่ได้มีส่วนช่วยทำให้สิ่งนี้เกิดขึ้น
• หวังว่าความพยายามในวันนี้จะกลายเป็นจุดเปลี่ยนที่เปิดอนาคตให้กับแพ็กเกจจำนวนมหาศาลและหลากหลายที่นักพัฒนาหลายล้านคนใช้งานทุกวัน

[GN⁺]

ความคิดเห็นจาก Hacker News

• หลายคนใช้ multiprocessing กันมาก และมีการพูดถึงว่าต้นทุนในการสร้างโปรเซสค่อนข้างสูง

  • มีฟีเจอร์ SharedMemory อยู่แล้ว แต่ไม่เข้าใจว่าทำไมถึงไม่ถูกใช้บ่อยกว่านี้

  • ย้ำว่าประสบการณ์ใช้งาน ShareableList นั้นดีมาก

  • บน Unix ความเร็วในการสร้างโปรเซสอยู่ในระดับต่ำกว่า 1ms

    • แต่การเริ่มโปรเซสของ Python interpreter อาจใช้เวลา 30ms~300ms ตามจำนวน import
    • เพราะต่างกัน 1~2 หลัก ดังนั้นตัวเลขที่แม่นยำจึงสำคัญ
    • CGI เป็นข้อยกเว้นในเรื่องนี้ และถ้าเป็น C·Rust·Go จะไม่มีปัญหา
    • ยกตัวอย่างว่า sqlite.org ก็ใช้รูปแบบแยกโปรเซสต่อคำขออยู่เช่นกัน

  • ShareableList แชร์ได้แค่ atomic scalar กับ bytes·สตริงเท่านั้น

    • วัตถุแบบ structured ของ Python ยังมีต้นทุนจากการ serialize เช่น pickle dump และมีต้นทุนหน่วยความจำจากการคัดลอกแยกต่อโปรเซส

  • มีประสบการณ์ที่ประสบความสำเร็จมากกับการแชร์อาร์เรย์ของ numpy

    • วิธีแชร์แบบ explicit ไม่ถือเป็นภาระมากนัก เมื่อเทียบกับความยากในการดีบักปัญหาที่เกิดจากการแชร์กันโดยเผลอระหว่างเธรด
    • หลายคนประเมินสูงเกินไปว่าเธรดดีกว่า multiprocessing แค่ไหน
    • กังวลว่าถ้า GIL ถูกปลด จะต้องดีบัก segfault แบบสุ่มมากขึ้นหรือไม่
    • พูดถึงว่าคนก็ไม่ได้บ่นหนักนักที่ JavaScript ไม่รองรับ threading บน shared memory
    • ตีความว่าเป็นเพราะ JavaScript เร็วพอจนไม่ค่อยจำเป็น
    • อยากให้มีความพยายามปรับปรุงประสิทธิภาพพื้นฐานของ Python มากกว่านี้

  • เพราะโปรเซสตายแยกกันได้ ถ้าโปรเซสที่กำลังแก้ไขโครงสร้างข้อมูลใน shared memory โดยยังถือ lock อยู่ตายไป การกู้คืนจะยาก

    • ยกตัวอย่างโครงสร้าง shared memory ของ Postgres และกรณีที่ต้องปิด backend process ทั้งหมด
    • ส่วนเธรดตายไปพร้อมกัน จึงทำให้คนรับรู้ปัญหาประเภทนี้น้อยกว่า

  • shared memory ใช้งานได้เฉพาะบนฮาร์ดแวร์เฉพาะทาง

    • ในสภาพแวดล้อมอย่าง AWS Fargate ไม่มี shared memory ต้องใช้เครือข่ายหรือไฟล์ซิสเต็มแทน ทำให้ latency สูงขึ้น
    • การคัดลอกโปรเซสแบบ fork ก็มีปัญหาอีกแบบ
    • จากประสบการณ์จริง green thread และ actor model มีประสิทธิภาพกว่ามาก

• สงสัยว่าการเอา GIL ออกจะมีผลอย่างอื่นกับโค้ด Python แบบ multithreaded นอกจากเรื่องประมวลผลขนานหรือไม่

  • เข้าใจว่าเหตุผลที่ GIL คงอยู่ไม่ใช่เพราะ multithread ต้องพึ่งมัน แต่เพราะการเอา GIL ออกทำให้ implementation ของ interpreter, C extension และความเร็วของโค้ด single-thread แย่ลง

  • สงสัยว่า Free-threaded Python ยังมีการรับประกันแบบเดิมหรือไม่ ว่าสามารถถูกแย่ง execution ได้ทุกเมื่อที่ขอบเขตของ bytecode

  • หรือว่าต้องเขียนต่างไป เช่น ต้องใช้ lock มากขึ้น

  • free-threaded Python ก็ยังมีการรับประกันส่วนใหญ่เหมือนเดิม

    • เพียงแต่ถ้าไม่มี free-threading คนมักจะใช้ฟีเจอร์ threading น้อยกว่า ทำให้บั๊กจากการถูกแย่ง execution ตรงจุดขอบเขตไม่ค่อยเกิดขึ้นจริง
    • เมื่อเพิ่ม free-threading จะมีบั๊กโผล่ออกมามากขึ้น
    • ไม่จำเป็นต้องใช้วิธีอ้อมแบบ multiprocess อีก ทำให้โค้ดฝั่งผู้ใช้เรียบง่ายขึ้น; มองว่าคุ้มกับความซับซ้อนที่เพิ่มขึ้นใน interpreter
    • ปัญหาความซับซ้อนของ C extension หนักกว่าสำหรับ sub-interpreter มากกว่า free-threading; ทีม numpy ก็ประกาศชัดว่าไม่สามารถรองรับ sub-interpreter ได้
    • ตอนนี้ numpy รองรับ free-threading แล้ว และกำลังแก้บั๊กที่เหลืออยู่
    • ความเร็วแบบ single-thread ที่ช้าลงเล็กน้อย (ระดับเลขหลักเดียว %) เป็น trade-off ที่ยอมรับได้

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

    • จากการทดลองกับ PyTorch พบว่าใช้ CPU มากขึ้น 10 เท่า แต่ได้ throughput ของงานเพียงครึ่งเดียว
    • คาดว่าจะดีขึ้นเมื่อเวลาผ่านไป และรู้สึกยินดีเพราะรอสิ่งนี้มา 20 ปีแล้ว

  • race condition อาจเกิดถี่ขึ้น จึงต้องระวังมากขึ้นเวลาเขียน Python แบบ multithread เพื่อให้มั่นใจในความถูกต้อง

• มีข่าวว่า Microsoft ยุบทีม Faster Python ไปแล้ว

  • เป็นเพราะผลประกอบการคาดการณ์ปี 2025 ไม่ถึงเป้า จึงไม่ได้รักษาทีมไว้

  • ต่อจากนี้จะคอยดูว่าจะยังมีการปรับปรุงประสิทธิภาพใน CPython เพิ่มอีกหรือไม่ หรือจะมีบริษัทอื่นมาสนับสนุนหรือเปล่า

  • ดูเหมือน Facebook (Meta) ยังสนับสนุนอยู่บางส่วน

  • มีการพูดถึงว่ากำหนดการของ Microsoft ล่าช้ากว่าที่เคยสัญญาไว้อย่างมาก

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

  • แม้ผลลัพธ์นี้จะน่าเสียดาย แต่ก็พูดว่าตัวเองคาดไว้แล้วเพราะไม่เคยเชื่อคำสัญญาระยะยาวของ Microsoft

  • มีข่าวลือว่าช่วงหลัง Google ก็เหมือนจะปลดทั้งทีมพัฒนา Python เช่นกัน

    • สงสัยว่าสองกรณีนี้มีสาเหตุร่วมตามยุคสมัยหรือมีตัวร่วมบางอย่างหรือไม่

  • น่าเสียดายมาก แต่ให้ความรู้สึกว่าหลังจาก embrace & extend แล้ว ก็เหลืออยู่อีกอย่างเดียว

• สงสัยว่ามีแค่ตัวเองหรือไม่ที่กังวลกับการหายไปของ GIL ใน Python

  • ไม่ว่าภาษาไหน โค้ด multithread ที่ซับซ้อนก็มักเชื่อถือได้ยาก และ Python ยิ่งน่ากังวลกว่าเพราะมีความเป็น dynamic สูง

  • ไม่ได้มีแค่คนเดียวที่กลัวการเปลี่ยนแปลงนี้ และความกังวลนั้นอาจไม่มีเหตุผลทางตรรกะนัก

    • GIL เป็น technical debt ล้วน ๆ จึงควรถูกเอาออกเพื่อประโยชน์ของชุมชน
    • ทุกวันนี้ใน Python คนส่วนใหญ่ใช้ non-blocking IO และ async แทนเธรด
    • ถ้าไม่ใช้เธรด ก็ไม่มีอะไรเปลี่ยนจากการเอา GIL ออก; C library ก็ปลอดภัยในแบบ single-thread
    • มีสิ่งที่ต้องระวังก็ต่อเมื่อใช้งานเธรดจริง ๆ
    • โค้ด Python แบบเธรดที่เขียนอย่าง naïve ก่อนหน้านี้ทำงานคล้าย single-thread เพราะโดน GIL ขวาง แต่จากนี้อาจเร็วขึ้นบ้างและอาจมีบั๊กมากขึ้นด้วย
    • ทางแก้คือไม่ใช้เธรด หรือถ้าจะใช้ก็ต้องเรียนรู้ให้ถูกต้อง
    • ต่อไปน่าจะมี abstraction ที่ดีขึ้น และหวังว่าจะได้เห็นชุมชนคุยกันเรื่อง structured concurrency เป็นต้น

  • ตัวเองใช้ asyncio อย่างจริงจังอยู่แล้ว

    • แม้จะเป็น single-thread แต่ก็เขียน Python ที่ concurrent ได้อย่างสนุก คล้ายใช้ Node.js
    • สำหรับงานเว็บ·เครือข่าย แนะนำวิธีนี้

  • คาดว่าในสาย ML/AI จะเป็นแบบที่ผู้เชี่ยวชาญสร้างไลบรารีซับซ้อนก่อน แล้วส่งต่อให้ผู้ใช้ทั่วไปใช้งาน

    • ตอนนี้มีหลายกรณีที่ GIL ของ Python กลายเป็นคอขวดร้ายแรง
    • จึงไปเรียนภาษา Go; มองว่าเป็นระดับ abstraction ที่รองจาก Python แต่สูงกว่า C/C++ และรองรับเธรดได้ดีจริง
    • รูปแบบคอมไพเลอร์ก็เป็นพื้นหลังสำคัญพอ ๆ กับเรื่อง threading

  • แม้อาจเป็นการปลุกความกังวลเกินเหตุ แต่ก็เตือนว่าตอนนี้ LLM เรียนรู้จากโค้ด Python ที่อยู่ภายใต้สมมติฐานว่ามี GIL มาตลอดหลายสิบปี

  • การมีหรือไม่มี GIL เกี่ยวข้องเฉพาะคนที่ต้องการงานแบบหลายคอร์เท่านั้น

    • ถ้าตอนนี้ก็ไม่ได้สนใจ threading·multiprocessing อยู่แล้ว แทบไม่มีอะไรเปลี่ยนในทางปฏิบัติ
    • ปัญหา race condition ก็เกิดได้ไม่ว่ามีหรือไม่มี GIL

• ใช้ Python บ่อย แต่ไม่ใช่ผู้เชี่ยวชาญ และบางครั้งก็ใช้ concurrent.futures เพื่อรันฟังก์ชันง่าย ๆ หลายตัวพร้อมกัน

  • สงสัยว่าผู้ใช้ลักษณะนี้ต่อไปควรเปลี่ยนอะไรบ้าง

  • เพราะเธรดไม่ถูก GIL ผูกไว้อีกต่อไป โดยรวมจึงเร็วขึ้น

    • ถ้าจัดการ lock ของอ็อบเจ็กต์ที่แชร์กันให้ดีอยู่แล้ว ก็ไม่ต้องกังวลอะไรเพิ่ม

• แชร์มุมมองจากประสบการณ์ทำงานเป็นโปรด้วย Python มา 20 ปี

  • เวลาที่ต้องใช้เธรดจริง ๆ มักจำกัดอยู่ในกรณีที่เลี่ยง message passing ไม่ได้

    • ecosystem ของ Python มีวิธีอ้อมสำหรับทุกสถานการณ์แบบนี้อยู่แล้ว
    • เพราะมีหลุมพรางในการจัดการหลายเธรดมากมาย (เช่น lock) ต่อไปจึงอาจจำเป็นแค่ในบางไลบรารี·บางโดเมนเท่านั้น
    • ถ้าอยากรีดประสิทธิภาพจาก Python ล้วนให้มากที่สุด ก็ใช้ไลบรารีที่อิง native code ได้ (เช่น Pypy, numba)
    • นวัตกรรมด้านประสิทธิภาพที่แท้จริงของ Python คือ async programming; แนะนำให้ลองเรียนจริงจัง

  • อีกคนใช้ Python มานานพอ ๆ กันและเห็นด้วย แต่ขออธิบายต่างออกไปเล็กน้อย

    • เพราะ Python threads แย่มาก วิธีอ้อมสารพัดจึงถูกพัฒนาขึ้นมาเพื่อหลีกเลี่ยงมัน
    • เคยพยายามเร่งงาน CPU-bound ด้วยเธรดให้เร็วขึ้น 2 เท่า แต่ติดปัญหา GIL เลยต้องเปลี่ยนไปใช้ multiprocessing; แล้วก็มีต้นทุนจากการ serialize โครงสร้างข้อมูล ทำให้ใช้คอร์เพิ่ม 2 เท่าแต่เร็วขึ้นแค่ 1.5 เท่า เป็นประสบการณ์ที่ไม่มีประสิทธิภาพ
    • ถ้ามีการรองรับเธรดที่ดี ก็คงมีหลายสภาพแวดล้อมที่อยากใช้งาน; ที่ผ่านมาต้องใช้แนวทางทดแทนต่าง ๆ เพราะมันไม่มี
    • ถ้าเหมาะกับสถานการณ์ก็ขอแนะนำ async อย่างจริงจัง (glyph, คุณพูดถูกแล้ว!)

• แม้จะเป็นภาพ AI แต่ก็แปลกใจที่งูถูกวาดให้มีหางสองอัน

  • มีคนช่วยแซวว่าให้ปล่อยผ่านไปเงียบ ๆ; ถ้าบทความเกี่ยวกับ Python มีรูปงูประกอบ ก็มักเป็นสัญญาณขำ ๆ ว่าไม่ค่อยคุ้มจะใส่ใจนัก

  • เสนอชื่อเล่นขำ ๆ ว่า Confusoborus

• มีคนชี้ว่าดูเหมือนงูในภาพส่วนหัวมีหางสองอัน

  • มีมุกตอบว่าเหมือนเพิ่งสร้างเธรดที่สองขึ้นมาในโปรเซสเดียวกัน

• นอกจากการรองรับจากไลบรารีแล้ว สงสัยว่ายังมีข้อจำกัดอื่นไหมในการรัน WSGI และ Celery worker แบบโปรเซสเดียว

  • ไม่มีข้อจำกัด แต่แนวทางนี้ยังไม่ใช่ฟีเจอร์ระดับ first-class ของภาษา
    • อธิบายว่า GIL คือปัญหา technical debt
    • และยังมีองค์ประกอบอื่นนอกจากเรื่อง parallelism ที่ต้องปลด GIL ด้วย

• มองว่านี่เป็นงานวางรากฐานขนาดมหาศาลสำหรับยุคประสิทธิภาพในอนาคต