5. jūnijā Python steering council pieprasīja apturēt visu jauno darbu pie CPython JIT kompilatora. Kods pagaidām paliek main zarā, bet ar skaidru nosacījumu: ja sešu mēnešu laikā neparādās apstiprināts standarta PEP, JIT tiek izņemts un tā attīstība pārceļas ārpus oficiālā repozitorija.
JIT (just-in-time) kompilators CPython nonāca kopā ar PEP 744, kas ir tikai informatīvs dokuments. Praksē tas nozīmē, ka lielu eksperimentu ielaida main zarā, neatbildot uz jautājumiem, kurus parasti prasa šāda mēroga pārveidojums: kas kodu uzturēs ilgtermiņā, kā tas sadzīvo ar atkļūdotājiem un profileriem, un pēc kādiem skaitļiem spriest, vai tas vispār bija tā vērts.
Kas notika 5. jūnijā
Steering council paziņoja, ka uz main vairs nedrīkst nonākt jaunas JIT funkcijas, optimizācijas vai veiktspējas darbs. Kļūdu labojumi un drošības ielāpi esošajam kodam turpina ienākt kā parasti. Padome arī atzina savu daļu atbildības — ņemot vērā izmaiņu apjomu un sarežģītību, tā pati nebija pietiekami stingri sekojusi procesam, kad JIT sākotnēji tika pieņemts.
Termiņš ir seši mēneši no paziņojuma. Diskusijā to gan precizēja: tas ir elastīgs mērķis. Absolūta nogriezuma nav. Ja apstiprināts standarta PEP šajā logā neparādās, kods no main jāizņem un darbs jāpārceļ uz atsevišķu repozitoriju. Formāli tas neizdzēš JIT no pasaules, taču izmet to no galvenās izstrādes plūsmas un no nākamajiem oficiālajiem laidieniem, līdz process ir sakārtots.
Faster CPython komandas dalībnieks Mārks Šenons (Mark Shannon) lūdza dot elpošanas telpu — mēnesi vai divus, lai varētu turpināt jau iesāktos uzlabojumus:
Visas attīstības apturēšana, līdz PEP ir apstiprināts, mūs nostāda neērtā situācijā.
Lūgums ir saprotams. Daļa uzlabojumu jau bija ceļā, un sešu mēnešu iesaldēšana nozīmē, ka gatavs kods paliek gaidīšanā, kamēr rit debates par dokumentu.
Kāpēc informatīvs PEP nebija gana
Atšķirība starp informatīvu un standarta PEP nav birokrātija. Informatīvs PEP apraksta, kas ir izdarīts; standarta PEP prasa atbildes uz jautājumiem, kas nosaka, vai funkciju var uzturēt gadiem. PEP 744 gadījumā atklāti palika trīs mezgli: nav apņēmušos ilgtermiņa uzturētāju, nav veikts drošības audits, un nav skaidrs, kā JIT sadzīvo ar ārpusprocesa rīkiem — atkļūdotājiem un profileriem.
Pēdējais mezgls skar ikvienu, kas kodu pēc palaišanas arī pēta. Atkļūdotāji un profileri paļaujas uz to, ka izpildāmais kods atbilst tam, ko rāda avota fails. JIT šo saikni sarežģī: mašīnkods, ko tas ģenerē, dzīvē var izskatīties citādi nekā baitkods, no kura tas radies. Ja rīks to nesaprot, izstrādātājs redz nepilnīgu ainu. Padomes arguments bija tiešs: eksperimentālu kompilatoru nevajadzēja iepludināt main zarā, balstoties uz dokumentu, kas neko no tā neatrisina.
Jaunajam PEP jāapraksta uzturēšanas plāns, saderība ar esošajiem rīkiem un free-threading būvēm, izmērāmi veiksmes kritēriji un attiecības ar trešo pušu JIT risinājumiem. Free-threading saderība te ir īpaši svarīga, jo CPython vienlaikus atsakās no globālās interpretatora slēdzenes, un divi lieli pārveidojumi vienā dzinējā nedrīkst cīnīties viens ar otru.
PEP 836 — glābšanas plāns
Atbilde ir PEP 836 ar nosaukumu “JIT Go Brrr”. Autori ir Savanna Ostrovska (Savannah Ostrowski), Kens Džins (Ken Jin) un Brandts Bučers (Brandt Bucher), un tas pašlaik ir melnraksta statusā. PEP nepasludina JIT par gatavu uzreiz. Tā vietā tas apraksta laikā ierobežotu ceļu, kurā JIT paliek main zarā, kamēr projekts izpilda konkrētus veiktspējas, saderības, rīku, izplatīšanas, drošības un uzturēšanas mērķus.
Plāns sadalīts posmos:
- 1. gads (Python 3.16): pāreja no trace-recording uz metožu bāzētu kompilāciju, labāka free-threading saderība un rīku atbalsts.
- 2. gads (Python 3.17): vismaz 20% veiktspējas pieaugums pyperformance testos.
- 2,5 gads (Python 3.17 RC): saderības pārbaude ar populārākajām PyPI pakotnēm.
Metožu bāzēta kompilācija maina arī to, cik viegli rīki saprot ģenerēto kodu. Trace-recording pieeja seko līdzi tam, ko programma reāli izpilda, un kompilē biežos ceļus; metožu bāzēta pieeja kompilē veselas funkcijas. Otrā ir prognozējamāka un rīkiem vieglāk saprotama, un tieši to padome pieprasa. Ja šie mērķi tiek sasniegti, JIT kļūst par oficiāli atbalstītu CPython daļu. Ja ne, padome atkārtoti izvērtē, vai to vispār paturēt.
Ko JIT dod šodien
Skaitļi paskaidro, kāpēc daļa kopienas negrib no JIT atteikties. Python 3.15 JIT dod aptuveni 4–12% ģeometriski vidējo paātrinājumu Tier 1 platformās — no 4,7% uz Windows līdz 12,6% uz macOS ar tailcalling ieslēgtu. Python 3.15 laidienā Kens Džins pārrakstīja JIT frontend uz trace-recording pieeju un pievienoja pamata reģistru piešķiršanu un in-place int un float operācijas. Tas palielināja JIT koda pārklājumu par 50%. Uz macOS AArch64 rezultāts bija 11–12% ātrāk nekā tail-calling interpretatoram un 5–6% ātrāk nekā parastajam interpretatoram uz x86_64 Linux.
Par komandu: Kens Džins šo darbu vadīja kā brīvprātīgais pēc tam, kad Faster CPython komanda 2025. gadā zaudēja galveno sponsoru. JIT joprojām ir eksperimentāls un ieslēdzas tikai tad, kad to pieprasa ar PYTHON_JIT=1. Ciešās skaitļošanas cilpas var iegūt daudz vairāk par vidējiem skaitļiem, I/O bremzēts kods — gandrīz neko. Tāpēc vienam projektam JIT dod jūtamu pieaugumu, citam praktiski neko.
Nākamais reālais pārbaudījums ir 20% latiņa Python 3.17 versijai. Tā ir robeža, kas atšķir eksperimentu no funkcijas, kuru steering council piekritīs uzturēt.
Avoti
- An announcement from the Steering Council regarding the JIT project — discuss.python.org
- PEP 836 – JIT Go Brrr: The Path to a Supported JIT Compiler for CPython
- PEP 744 – JIT Compilation
- Python 3.15’s JIT is now back on track — Ken Jin
- Python JIT compiler project under threat after steering council says proper process wasn’t followed — The Register
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.