5. jūnijā Python vadības padome (Steering Council) apturēja jaunu darbu pie JIT kompilatora: neviena jauna funkcionalitāte vairs nenonāk galvenajā koda zarā, kamēr projektu neapstiprina caur pilntiesīgu standarta PEP. Padome deva tam aptuveni sešus mēnešus — līdz šā gada decembrim. Ja PEP līdz tam neiziet kopienas caurskati, JIT kods tiek izņemts no galvenā zara, un tā izstrāde turpinās kaut kur ārpus CPython.
Tas skar funkciju, ko daudzi izstrādātāji vēl nemaz nav pamanījuši, jo pēc noklusējuma tā ir izslēgta. JIT nonāca CPython pirms diviem laidieniem, taču bez apstiprinājuma procesa, kādu prasa jebkura cita valodas izmaiņa. Tieši to padome tagad labo.
Kā JIT nonāca CPython
Kompilators parādījās Python 3.13 kā eksperimentāls papildinājums. Tas izmanto tehniku, ko sauc par copy-and-patch: būvēšanas laikā no iepriekš sagatavotiem mašīnkoda gabaliem tiek salīmēts izpildāmais kods, izvairoties no pilna kompilatora izpildlaikā. Lai to ieslēgtu, CPython jābūvē ar karogu --enable-experimental-jit — gatavajos instalatoros tā nav.
Problēma slēpjas dokumentā, kas JIT pavadīja. PEP 744 bija informatīvs, nevis lēmumu pieprasošs. Tas aprakstīja, ko JIT dara, bet neprasīja kopienai balsot par to un atstāja atvērtus vairākus pamatjautājumus: kurš uztur kompilatoru ilgtermiņā, kā tas sadzīvo ar free-threading (bezglobālās interpretatora slēdzenes) būvējumu, vai tas strādā kopā ar profilētājiem un atkļūdotājiem, un pēc kādiem mērāmiem kritērijiem vērtēt, vai tas gatavs.
Kāpēc padome nospieda pauzi
Vadības padomes paziņojumā teikts, ka eksperimentālā kārtība sevi izsmēlusi. Kamēr JIT galvenajā zarā tika papildināts bez kopienas apstiprinājuma, auga kods, ko neviens formāli nebija apņēmies uzturēt. Iesaldēšana ir konkrēta: labojumus pieņem, bet jaunu funkcionalitāti — ne, līdz standarta PEP iziet caurskati.
Sešu mēnešu termiņš nav draudi izmest kodu tāpat vien. Tas ir spiediens uzrakstīt to, kas trūkst — atbildības, uzturēšanas un veiktspējas kritērijus melns uz balta.
PEP 836 — atbilde četrās nedēļās
2. jūlijā JIT komanda iesniedza PEP 836 ar nosaukumu “JIT Go Brrr”. To sagatavoja Kens Džins (Ken Jin), Savanna Ostrovski (Savannah Ostrowski) un Brendts Bučers (Brandt Bucher). Dokuments apraksta ceļu, pa kuru JIT no eksperimenta kļūtu par oficiāli atbalstītu CPython daļu.
Centrālais ir mērāms veiktspējas slieksnis. PEP nosaka minimālo latiņu, zem kuras JIT paturēt galvenajā zarā nav vērts:
Vismaz 20 % ģeometriskā vidējā uzlabojums pyperformance testos JIT plus free-threaded būvējumam salīdzinājumā ar to pašu būvējumu bez JIT — mērīts pirmā līmeņa (Tier 1) platformās.
Termiņš šim rādītājam ir Python 3.17 pirmā beta versija. PEP arī apraksta tehnisku pārkārtošanos: pāreju no trases (trace) balstīta priekšgala uz metožu balstītu priekšgalu, kas kompilatoru padara vieglāk uzturamu un testējamu. Blakus tam nāk prasības par saderību ar free-threading, atkļūdotājiem un profilētājiem — tieši tie jautājumi, ko PEP 744 atstāja atvērtus.
Ko no tā iegūst kods šodien
Pašreizējie skaitļi ir pieticīgi, bet reāli. byteiota apkopotie mērījumi rāda aptuveni 8–9 % paātrinājumu uz x86-64 Linux un 12–13 % uz AArch64 macOS. Ieguvumu jūt uz procesora balstīta slodze — cilpas, skaitļošana, datu apstrāde. Tīmekļa aizmugure, kas lielāko daļu laika gaida datubāzi vai citu servisu, no JIT gandrīz neko nemana.
Praktiski nekas nemainās izstrādātājam, kurš JIT nelieto. Tas joprojām jāieslēdz ar būvēšanas karogu, un gatavie laidieni to nesatur. Mainās projekta liktenis: 20 % latiņa nosaka, vai divu gadu darbs paliek CPython vai aiziet dzīvot atsevišķā repozitorijā, zaudējot uzmanību un līdzstrādniekus.
Nākamais atskaites punkts ir Python 3.17 pirmā beta versija. Līdz tai JIT paliek aiz --enable-experimental-jit, un tā PEP tiek caurskatīts pēc tiem pašiem noteikumiem, kas attiecas uz jebkuru citu valodas izmaiņu.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.