คำประกาศจาก Steering Council เกี่ยวกับโครงการ JIT

 (discuss.python.org)
1 คะแนน โดย GN⁺ 5 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • JIT compiler แบบทดลองของ CPython ได้รับการพัฒนาบนสาขา main มาหลายปี และล่าสุดได้แสดงให้เห็นถึงการปรับปรุงประสิทธิภาพจริง แต่หากจะคงไว้เป็นฟีเจอร์ที่รองรับอย่างเป็นทางการ จำเป็นต้องผ่านการพิจารณา PEP อย่างเป็นทางการ
  • PEP 744 ครอบคลุมการออกแบบเริ่มต้นและเกณฑ์สำหรับการเปลี่ยนเป็นฟีเจอร์ถาวร แต่ยังไม่มีข้อสรุปร่วมกันเกี่ยวกับผู้ดูแลระยะยาว การทบทวนด้านความปลอดภัย การรองรับการดีบักและเครื่องมือ process ภายนอก การรับประกันที่ระดับ runtime และภาระหน้าที่ของผู้จัดทำแพ็กเกจสำหรับการแจกจ่ายต่อและ downstream
  • Python Steering Council ได้ร้องขออย่างเป็นทางการให้จัดทำ Standards Track PEP เพื่อทำให้ JIT เป็นฟีเจอร์ที่รองรับและไม่ใช่ฟีเจอร์ทดลองของ CPython และได้ขอให้หยุดการนำฟีเจอร์ใหม่ การเพิ่มประสิทธิภาพ และงานด้านสมรรถนะใหม่ ๆ เข้าสู่สาขา main จนกว่าจะมีการยอมรับ PEP
  • PEP ฉบับใหม่ต้องครอบคลุมการบำรุงรักษาระยะยาว ความเข้ากันได้กับฟีเจอร์และเครื่องมือเดิมของ CPython ตัวชี้วัดความสำเร็จที่วัดได้พร้อมกำหนดเวลา ความสัมพันธ์กับ JIT ของบุคคลที่สามอย่าง CinderX·Numba·PyTorch และเสถียรภาพของสถาปัตยกรรมปัจจุบัน
  • หากไม่มีการยื่น PEP แก้ไขให้แล้วเสร็จ หรือไม่ได้รับการยอมรับภายใน 6 เดือน จะต้องนำ โค้ด JIT ออกจากสาขา main และพัฒนาต่อไปนอกที่เก็บ Python main

พื้นหลังและคำขออย่างเป็นทางการ

  • Just-In-Time compiler แบบทดลองของ CPython เป็นงานที่ core developer และผู้ร่วมพัฒนาหลายคนพัฒนาบนสาขา main มาตลอดหลายปีที่ผ่านมา และการปรับปรุงประสิทธิภาพล่าสุดก็เป็นผลลัพธ์ที่จับต้องได้และน่าตื่นเต้น
  • มาตรการนี้ไม่ใช่การวิจารณ์งาน JIT หรือผู้มีส่วนร่วม แต่เป็นการประเมินว่าถึงเวลาต้องทบทวนสถานะที่ไม่เป็นทางการของ JIT ภายในโครงการ CPython ใหม่ เพราะโครงการดำเนินมานานและผ่านการออกแบบใหม่มาหลายครั้ง
  • JIT ถูกนำเข้า main ครั้งแรกในฐานะงานทดลอง และ PEP ที่เกี่ยวข้องคือ PEP 744 ก็เป็น Informational PEP
  • PEP 744 ครอบคลุมการออกแบบเริ่มต้นและกล่าวถึงเกณฑ์คร่าว ๆ ที่ JIT อาจกลายเป็นฟีเจอร์ถาวรได้ แต่ยังเปิดคำถามไว้เกี่ยวกับผู้ดูแลระยะยาว การทบทวนด้านความปลอดภัย การรองรับการดีบักและเครื่องมือ process ภายนอก การรับประกันระดับ runtime และภาระหน้าที่ของผู้แจกจ่ายต่อกับผู้จัดทำแพ็กเกจ downstream
  • Python Steering Council เห็นว่าการเปลี่ยนแปลงที่มีความซับซ้อนและขอบเขตระดับนี้ควรผ่านกระบวนการที่เข้มงวดกว่านี้ และคำถามที่ยังไม่คลี่คลายเหล่านี้เป็นข้อผูกพันที่ชุมชนควรพิจารณาและหาฉันทามติผ่านกระบวนการ PEP
  • หากจะทำให้ JIT เป็นฟีเจอร์ที่รองรับและไม่ใช่ฟีเจอร์ทดลองของ CPython จำเป็นต้องมี Standards Track PEP ที่ครอบคลุมทั้งการรับประกัน คำมั่นด้านการบำรุงรักษา และผลกระทบต่อผู้จัดทำแพ็กเกจสำหรับการแจกจ่ายต่อ พร้อมทั้งต้องผ่านการหารือของชุมชนและกระบวนการยอมรับหรือปฏิเสธอย่างเป็นทางการจาก Steering Council
  • จนกว่า PEP ดังกล่าวจะได้รับการยอมรับ ไม่ควรนำงานพัฒนา JIT ใหม่เข้าสู่สาขา main โดยฟีเจอร์ใหม่ การเพิ่มประสิทธิภาพ และงานด้านสมรรถนะใหม่จะอยู่ในขอบเขตของการหยุดชั่วคราวนี้
  • ยังสามารถทำการแก้บั๊กและแก้ไขด้านความปลอดภัยต่อไปได้ โดยขอบเขตของคำขอให้หยุดมีผลเฉพาะกับการนำฟีเจอร์ JIT เพิ่มเติมเข้าสู่ระบบก่อน PEP ได้รับการยอมรับ

ประเด็นที่ PEP ต้องครอบคลุมและกรอบเวลา 6 เดือน

  • แม้จะไม่ได้มีเจตนาจะเรียกร้องข้อเสนอแข่งขัน แต่ตอนนี้ก็เป็นจังหวะที่เหมาะสมในการหารือข้อเสนอทางเลือกด้วย และสอดคล้องกับมุมมองเดิมที่ว่าไม่ควรทำการทดลองบนสาขา main ของ CPython โดยไม่มี PEP
  • แทนที่จะเสนอ JIT implementation เดียว อาจเหมาะสมกว่าหาก PEP จะอธิบายโครงสร้างพื้นฐาน JIT ที่รองรับกลยุทธ์การติดตั้งใช้งานได้หลายแบบ
  • เนื่องจากยังมีการเสนอแนวทาง JIT tracing ที่มีอนาคตอีกหลายแบบอย่างต่อเนื่อง โครงสร้างพื้นฐานจึงไม่ควรผูกแน่นกับกลยุทธ์เดียว แต่ควรเอื้อต่อการทดลองและประเมินแนวทางเช่นนั้นภายใน CPython ได้ง่าย
  • PEP ต้องวางแผนให้ชัดเจนว่าจะทำให้ subsystem ที่มีขนาดและความซับซ้อนระดับนี้คงอยู่และได้รับการบำรุงรักษาในระยะยาวอย่างไร รวมถึงจะส่งผลอย่างไรต่อผู้ดูแลและผู้ร่วมพัฒนาที่ไม่ได้มีส่วนร่วมกับ JIT โดยตรง
  • PEP ต้องครอบคลุมความเข้ากันได้กับฟีเจอร์และเครื่องมือเดิมของ CPython และกล่าวถึงปฏิสัมพันธ์กับ JIT รวมถึงการรับประกันต่าง ๆ อย่างกว้างและละเอียด เช่น free-threading, profiler และ debugger
  • PEP ต้องมีตัวชี้วัดความสำเร็จที่ชัดเจน วัดได้ และมีกรอบเวลา โดยครอบคลุมเป้าหมายและช่วงเวลาเกี่ยวกับสมรรถนะ ขอบเขตการรองรับแพลตฟอร์ม และ memory overhead
  • PEP ต้องครอบคลุมความสัมพันธ์กับ JIT compiler อื่น ๆ โดยชี้ให้ชัดว่าเป็นการออกแบบที่ให้โครงสร้างพื้นฐานทั่วไปซึ่งความพยายามอื่นสามารถนำไปใช้ต่อได้หรือไม่ และคาดว่าจะเข้ากันได้หรือไม่เข้ากันได้กับ JIT ของบุคคลที่สามอย่าง CinderX, Numba และ PyTorch
  • PEP ต้องครอบคลุมด้วยว่ามองว่าสถาปัตยกรรม JIT ปัจจุบันมีเสถียรภาพแล้วหรือไม่ หรือยังมีแนวโน้มจะเปลี่ยนแปลงอีกมาก
  • รายการนี้ไม่ใช่รายการครบถ้วนสมบูรณ์ และอาจมีประเด็นเพิ่มเติมเมื่อการหารือของชุมชนดำเนินต่อไป
  • ได้กำหนดกรอบเวลา 6 เดือนสำหรับการยื่นและหาข้อยุติของ PEP และหาก PEP ดังกล่าวไม่ได้รับการยอมรับภายในช่วงเวลานี้ จะต้องนำโค้ด JIT ออกจากสาขา main และพัฒนาต่อไปนอกที่เก็บ Python main
  • ข้อกำหนดนี้ไม่ได้หมายถึงการยุติโครงการ แต่เป็นกระบวนการเพื่อสร้างความชัดเจนและคำมั่นอย่างชัดแจ้งจากชุมชนที่จำเป็นต่อการเปลี่ยนแปลงขนาดใหญ่ใน CPython runtime

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

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

 
GN⁺ 5 시간 전
ความคิดเห็นจาก Lobste.rs

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

  • ข้อเสนออินเทอร์เฟซที่เปิดให้มี การติดตั้ง JIT ต่างกันได้ ดูเหมือนจะเข้าใจผิดอย่างมากว่าการทำ JIT ประสิทธิภาพสูงต้องการอะไร แม้ทีมที่ทำ JIT จะมีปัญหาหลายอย่าง แต่หนึ่งในปัญหาใหญ่ดูเหมือนจะเป็นการที่พวกเขาไม่สามารถ หรือไม่ต้องการ เปลี่ยนโครงสร้างข้อมูลหลักของรันไทม์ครั้งใหญ่
    แน่นอนว่า Python ก็มีปัญหาที่แทบจะเปิดเผยทั้งอิมพลีเมนเทชันออกมาเป็น API อยู่แล้ว ถึงอย่างนั้น ถ้ามีใครทำอะไรที่ไม่ดี คุณก็ยังบังคับให้เขาเขียนส่วน type ใหม่ได้ แต่การจะทำแบบนั้นได้ต้องมีชุมชนที่ให้ความสำคัญกับประสิทธิภาพอย่างจริงจัง ในทางประวัติศาสตร์ Python รับมือด้วยวิธีที่ว่าไลบรารีที่ต้องการประสิทธิภาพจะไม่เขียนด้วย Python อยู่แล้ว และนั่นก็ส่งผลต่อการจัดลำดับความสำคัญ ทำให้นึกถึงสมัยก่อนที่มีการเปรียบเทียบประสิทธิภาพภาษา โดยเอาการติดตั้งอัลกอริทึมพื้นฐานมาเทียบกับอิมพลีเมนเทชัน Python ที่จริง ๆ แล้วเป็นแค่ตัวห่อรอบ C library ประสิทธิภาพสูงที่ขัดเกลามาอย่างดี

    • ข้อเสนออินเทอร์เฟซ JIT ดูเหมือนจะได้แรงบันดาลใจจาก Ruby และใน Ruby ก็ดูเหมือนจะใช้ได้ผลค่อนข้างดี ดังนั้นต่อให้ Ruby จะไม่มี JIT ที่เร็วสุดขีดก็คงไม่เป็นไร ถ้า Python JIT ทำงานได้พอ ๆ กับ Ruby JIT ก็น่าจะมีคนพอใจมากแล้ว

    • ยังไม่ค่อยเข้าใจว่าทำไมถึงบอกว่า “ข้อเสนออินเทอร์เฟซที่เปิดให้มีการติดตั้ง JIT ต่างกันได้ เข้าใจผิดอย่างมากเกี่ยวกับสิ่งที่ JIT ประสิทธิภาพสูงต้องการ”
      อย่างที่พูดไป Python มีสถานการณ์ที่เปิดเผยอิมพลีเมนเทชันออกมาเหมือนเป็น API ก็จริง แต่ด้วยเหตุผลเดียวกัน JIT เองก็กำลังเรียกใช้ API เหล่านั้นอยู่เหมือนกัน จริง ๆ แล้วมีบางฟังก์ชันที่ถูกเปิดเป็นสัญลักษณ์สาธารณะให้ลิงเกอร์เห็นเพราะ JIT ต้องใช้ด้วย ส่วนตัวฉันกำลังทำ method JIT ไม่ใช่ tracing JIT และก็สนับสนุนแนวคิด JIT แบบปลั๊กอินต่อสาธารณะมาโดยตลอด

  • สงสัยว่าทำไมถึงไม่ส่งเรื่องนี้เป็นคำขอแบบไม่เปิดเผยต่อ นักพัฒนา JIT หลัก แต่กลับโพสต์เป็น ประกาศสาธารณะ

    • เพราะ Python เป็น โครงการโอเพนซอร์สที่ขับเคลื่อนโดยชุมชน แม้แต่ในโครงการแบบปิดก็ยังเคยมีประกาศลักษณะนี้หลุดออกมาเหมือนกัน

  • ดูเหมือนว่านักมานุษยวิทยาสักคนควรเขียนหนังสือเกี่ยวกับ ระบบราชการ ของโครงการซอฟต์แวร์โอเพนซอร์ส และ Python กับ Debian ก็ควรเป็นกรณีศึกษาหลัก
    ไม่ได้พูดในเชิงตำหนิ ระบบราชการแบบนี้สุดท้ายแล้วก็คือกระบวนการตัดสินใจแบบกระจายศูนย์และการสร้างฉันทามติ ซึ่งทำให้มันทำงานได้ดีในขนาดระดับนี้เป็นเรื่องยาก

    • Gabriella Coleman เป็นนักมานุษยวิทยาที่ทำงานภาคสนามกับ Debian หนังสือที่ออกมาจากงานนั้นคือ “Coding Freedom” แนะนำมาก

  • พูดตรง ๆ มันดูเหมือนอาการแบบเดียวกับที่นำไปสู่ Python 3 แต่ให้ผลตรงกันข้าม CPython ดูเหมือนจะมีอยู่เพื่อความสนุกของคนทำอิมพลีเมนเทชันเป็นหลัก และการเปลี่ยนแปลงนี้ก็น่าจะสร้างความไม่สะดวกค่อนข้างมากให้กับคนที่คุ้นเคยกับการแฮ็กในแบบปัจจุบัน
    อาจเป็นไปได้ว่าทิศทางที่ถูกต้องคือสนับสนุน JIT เวอร์ชันที่เป็นอิมพลีเมนเทชันแยกต่างหาก เปิดให้เปลี่ยนแปลงได้ และพยายามรักษาความเข้ากันได้กับ CPython เดิมแบบ best effort

    • ยังไม่ค่อยเข้าใจว่าคำว่า “อาการแบบเดียวกับที่นำไปสู่ Python 3 แต่ให้ผลตรงกันข้าม” หมายถึงอะไรแน่
      ส่วนที่บอกว่า “CPython มีอยู่เพื่อความสนุกของคนทำอิมพลีเมนเทชันเป็นหลัก” นั้น จากประสบการณ์ที่ได้มีปฏิสัมพันธ์กับ SC และ core developer แบบจำกัด ฉันกลับรู้สึกตรงกันข้าม คือโดยรวมแล้วพวกเขาดูทุ่มเทอย่างจริงจังกับการหาสมดุลอย่างสมเหตุสมผลระหว่างการสนับสนุนชุมชนเดิมต่อไปกับการเดินหน้าสู่อนาคต