CPython туршилтын JIT компилятороо төслөөс бүрэн хасахаар боллоо: Хүлээлт яагаад нурав?

Python хөгжүүлэгчдийн нийгэмлэг сүүлийн хоёр жил амьсгаа даран хүлээж, гүйцэтгэлийн шинэ эрин үе хэмээн найдаж байсан CPython-ийн албан ёсны Just-In-Time (JIT) компиляторын замнал түр өндөрлөлөө. LWN.net болон Python-ийн үндсэн хөгжүүлэгчдийн баталснаар, CPython-ийн эх кодын үндсэн салбар (main branch)-аас туршилтын JIT компиляторыг албан ёсоор хасахаар шийдвэрлэжээ.

Энэхүү шийдвэр нь JIT-ийг бүтээгдэхүүний түвшний албан ёсны боломж болгохоор зорьж байсан PEP 836 ("JIT Go Brrr") саналыг зохиогчид нь өөрсдийн хүсэлтээр татан авсны дараа гарсан юм. Ингэснээр удахгүй гарах Python 3.16 хөгжүүлэлтийн мөчлөгийн эхэнд уг дэд бүтцийг кодын сангаас бүрэн цэвэрлэхээр болов.

JIT компилятор анх яагаад CPython-д орж ирсэн бэ?

Python хэл хөгжүүлэгчдэд уян хатан, бичихэд хялбар хэдий ч гүйцэтгэлийн хувьд C, Rust, Go, тэр байтугай V8 хөдөлгүүртэй JavaScript (Node.js)-ээс хамаагүй удаан гэдгээрээ шүүмжлүүлсээр ирсэн. Үүний гол шалтгаан нь CPython интерпретатор байткод (bytecode)-ыг шууд машинаар унших хэлбэрт хөрвүүлэхгүйгээр программ хангамжийн түвшинд нэг бүрчлэн тайлбарлаж ажилладагт оршдог.

2024 онд Python 3.13 хувилбар гарах үед цөм хөгжүүлэгч Брандт Бухер (Brandt Bucher) анхны "Copy-and-patch" бүтэцтэй туршилтын JIT компиляторыг CPython-д оруулж ирсэн билээ.

Энэхүү технологи нь уламжлалт хүнд нүсэр JIT (жишээ нь PyPy эсвэл Java HotSpot) шиг ажиллахгүйгээр Clang ашиглан C кодыг урьдчилан загвар (stencil) болгон бэлдэж, ажиллах үед нь (runtime) шаардлагатай санах ойн хаягуудыг маш бага нөөцөөр "нөхөх" (patch) замаар машиныхаа код руу хөрвүүлдэг ухаалаг шийдэл байв.

Түүнчлэн Python 3.13-аас эхлэн туршигдаж буй GIL (Global Interpreter Lock)-гүй ажиллах буюу Free-threading горимд үүсэх гүйцэтгэлийн алдагдлыг (overhead) JIT компилятороор нөхнө гэсэн өөдрөг төсөөлөл байсан юм.

Удирдах зөвлөл яагаад "зогс" гэж тушаав?

JIT нь өнгөрсөн хугацаанд албан ёсны Standard PEP-гүйгээр, зөвхөн мэдээллийн шинжтэй PEP 744 дээр үндэслэгдэн CPython-ийн main салбарт хөгжүүлэгдэж байв. Энэ зун Python Steering Council (Удирдах зөвлөл) уг байдалд хяналт тавьж, "хэрэв JIT-ийг урт хугацаанд дэмжих албан ёсны бүрэлдэхүүн болгохыг хүсвэл бүх талын эрсдэлийг тооцсон жинхэнэ стандартын PEP өргөн барих ёстой" хэмээн ажиллагааг түр зогсоосон юм.

Улмаар Брандт Бухер, Саванна Островски, Кен Жин нар хамтран PEP 836-г боловсруулсан боловч дараах хэд хэдэн том бэрхшээлтэй тулгарчээ:

1. Хүлээлтэд хүрээгүй бодит хурд: PEP 836-ийн анхны зорилтот амлалт нь кодын гүйцэтгэлийг хамгийн багадаа 20 хувиар өсгөх явдал байсан. Гэвч бодит макро-тестүүд дээр авчирсан хурдны өсөлт ердөө 4–12%-ийн хооронд хэлбэлзэж байв. Энэ нь өдөр тутмын хэрэглээний программд үл анзаарагдах бага ялгаа байсан юм.
2. Архитектурын нарийн төвөгтэй байдал (Complexity budget): Хурдны багахан өсөлтийн хариуд төлөх өртөг нь асар өндөр байлаа. CPython төсөл бүх үйлдлийн систем, олон тооны CPU архитектур (x86_64, aarch64 г.м.), санах ойн менежмент дээр JIT-ийн түвшний цоорхой, алдааг засварлах давхар ачаалалтай болсон.
3. Нийцтэй байдлын хатуу шаардлага: Удирдах зөвлөл PyPI дээрх хамгийн эрэлттэй багцуудтай нийцтэй эсэхийг батлах шалгалтыг 2028 он хүртэл хойшлуулахгүйгээр нэн даруй эхлүүлэхийг шаардсан байна. Энэ бүхнийг шийдэхэд зохиогчдын багт цаг хугацаа болон хүний нөөцийн ноцтой дутагдал үүссэн тул тэд уг саналыг цуцалжээ.

Хөгжүүлэгчдэд юу өөрчлөгдөх вэ?

Энгийн Python хөгжүүлэгчдийн хувьд энэ мэдээнд сандрах шаардлагагүй. Шалтгаан нь:

• Таны сервер хэзээ ч JIT ашиглаж байгаагүй: Ихэнх Linux тархацууд болон үйлдвэрлэлийн орчинд PYTHON_JIT=1 флагийг гараар асааж тусгайлан CPython-ийг компил хийгээгүй л бол анхдагч тохиргоогоор ердийн интерпретатор ажилладаг. Төслийн JIT флагийг залгаагүй систем дээр тэр нь зүгээр л хоосон хувьсагч мэт үл тоомсорлогддог байв.
• Бодит хурдны өсөлтийг өгсөн "Specializing Adaptive Interpreter" хэвээр үлдэнэ: Python 3.11 болон 3.12 хувилбаруудаас эхлэн бидэнд бодитой мэдрэгдсэн 20–30%-ийн хурдны өсөлт нь JIT биш, харин PEP 659 буюу дасан зохицогч интерпретаторын гавьяа юм. Төрөл хувиргалт болон bytecode оновчлол хийдэг энэхүү суурь систем огт өөрчлөгдөхгүй.
• Free-threading (No-GIL) төсөл үргэлжилнэ: GIL-ийг хасах ажиллагаа төлөвлөгөөний дагуу урагшилж байгаа ч, түгжээгүй ажиллахад гарах санах ойн нэмэлт ачааллыг одоогоор JIT-ээр нөхөх боломжгүй болж, C-ийн цэвэр оновчлолуудад илүү найдах хэрэгтэй болж байна.

Архитектурын сургамж: "Шинэ бүхэн зөв биш"

Python нийгэмлэгийн энэхүү шийдвэр нь нээлттэй эхийн том төслүүд кодын цэвэр байдал болон системийн нарийн төвөгтэй байдлыг (software complexity) хэрхэн нухацтай авч үздэгийн тод жишээ боллоо.

Хэрэв шинэ технологийн авчрах бодит үр ашиг нь түүнийг засварлаж, хамгаалахад гарах зардлыг нөхөж чадахгүй бол түүнийг зоригтойгоор хасах нь урт хугацаандаа хэлний тогтвортой байдалд хамгийн эрүүл алхам болдог. JIT компиляторын мөрөөдөл CPython дээр бүрэн хаагдаагүй, магадгүй ирээдүйд илүү боловсронгуй шинэ санаачлагаар эргэн ирэх биз ээ.

---

Эх сурвалж: LWN.net (Python's experimental JIT to be removed), Python Enhancement Proposal (PEP 836), CPython GitHub Repository.