Python vadības padome 5. jūnijā apturēja jauna JIT kompilatora koda ielikšanu CPython main zarā. Kļūdu labojumi un drošības ielāpi paliek atļauti, viss pārējais gaida. Aizliegums beigsies tikai tad, kad kopiena apstiprinās standarta ceļa PEP, kas pamato JIT kā pastāvīgu CPython daļu. Padome deva aptuveni sešus mēnešus, tātad termiņš pienāk decembrī.
Atbilde uz šo prasību ir PEP 836 ar nosaukumu JIT Go Brrr. Dokumentā ir viens skaitlis, ap kuru griežas viss pārējais: līdz Python 3.17 JIT kopā ar bezGIL būvējumu pyperformance testos jārāda vismaz par 20 % labāks ģeometriskais vidējais rezultāts nekā tam pašam bezGIL interpretatoram bez JIT. Ja mērķi nesasniedz, kods no main iziet ārā.
Kā JIT nokļuva main zarā bez standarta PEP
JIT ienāca Python 3.13 2024. gadā kā eksperimentāla, pēc noklusējuma izslēgta funkcija. To ieslēdz būvēšanas laikā ar karogu --enable-experimental-jit. Aiz tās stāvēja tikai PEP 744, informatīvs dokuments, ko 2024. gada 11. aprīlī uzrakstīja Brandt Bucher un Savannah Ostrowski. Informatīvs PEP neko neapstiprina. Tas apraksta.
Tehniskais paņēmiens saucas copy-and-patch. JIT aizmuguri ģenerē no tā paša domēna valodas apraksta, no kā interpretatoru, tāpēc izmaiņas baitkoda definīcijās pašas pārceļas uz visām platformām bez atsevišķi uzturamas aizmugures. Cenu PEP 744 nosauca pats: atmiņas patēriņš pieaug par 10 līdz 20 %, uz aarch64-apple-darwin vairāk lielāku atmiņas lapu dēļ. Ātrums tolaik bija aptuveni tāds pats kā specializējošajam interpretatoram.
Padomes iebildums attiecas uz procedūru. Paziņojumu forumā publicēja padomes loceklis Pablo Galindo Salgado. Kamēr PEP nav pieņemts, main zarā nedrīkst nonākt ne jaunas JIT funkcijas, ne optimizācijas. Vairāku gadu darbs jau ir ieguldīts, taču dokumenta, kas pateiktu, kad JIT pārstāj būt eksperiments, joprojām nav.
Ko PEP 836 sola pa gadiem
Autori ir Savannah Ostrowski, Ken Jin un Brandt Bucher. Dokuments izveidots 2. jūlijā, mērķa versija ir 3.16, statuss joprojām melnraksts.
Sākuma punkts ir izmērīts. Python 3.15 JIT dod 4 līdz 12 % ģeometrisko vidējo pieaugumu Tier 1 platformās, atsevišķām testa mašīnām no 6,9 līdz 12,6 %. Grafiks ir sadalīts posmos:
- Pirmais gads, Python 3.16: vismaz 5 % pieaugums būvējumam ar GIL. Priekšgals pāriet no trases ierakstīšanas uz metožu principu. Klāt nāk saderība ar bezGIL būvējumu, profilētāju un atkļūdotāju atbalsts, kā arī vienkāršāka izplatīšana.
- Otrais gads, Python 3.17: tie paši 20 %, kas izšķir JIT likteni.
- Divarpus gadi: saderības pārbaudes ar reālām PyPI pakotnēm.
Atbalstīto platformu sarakstā ir Tier 1 mērķi: aarch64-apple-darwin, aarch64-unknown-linux-gnu, x86_64-unknown-linux-gnu un Windows uz MSVC. 32 bitu Windows PEP atstāj ārpusē maza lietotāju skaita dēļ. Uzturēšanas plāns paredz vairākus atbildīgos katram JIT posmam atsevišķi: priekšgalam, optimizatoram un aizmugurei. Darbu finansē Arm, FastAPI Labs un OpenAI.
Vidusdaļa un aizmugure paliek tādas, kādas ir. Pārrakstīts tiek priekšgals, tā daļa, kas izlemj, kuru koda gabalu vispār kompilēt. Trases priekšgals ņem to instrukciju virkni, kas izpildē faktiski nostrādāja, arī tad, ja tā stiepjas cauri vairākām funkcijām. Metožu priekšgals ņem funkciju kā veselumu. PEP autori paši raksta, ka pāreja sākumā var maksāt gan atmiņā, gan ātrumā.
Mērījums, no kura karājas projekta liktenis, ir formulēts precīzi. Salīdzina JIT kopā ar bezGIL būvējumu pret to pašu bezGIL būvējumu bez JIT. Būvējumam ar GIL atsevišķas 20 % prasības nav, tam pietiek ar pirmā gada 5 %.
Kritika apspriešanas pavedienā
Reakcija forumā nav vienota. Thomas Wouters uzskata, ka PEP sajauc divas atsevišķas lietas: kritērijus, pēc kuriem JIT kļūst par atbalstītu funkciju, kā arī konkrēto īstenošanas ceļu. Viņš iesaka tos šķirt un šaubās par grafika reālumu.
Mums nevajadzētu veidot arhitektūru tā, lai tā būtu vislabāk saprotama pašreizējiem kodola komandas locekļiem. Thomas Wouters, CPython izstrādātājs.
Cesare Di Mauro norāda, ka PEP nav neviena atmiņas patēriņa mērķa, lai gan pats dokuments atzīst, ka metožu priekšgals sākumā var patērēt vairāk atmiņas un strādāt mazliet lēnāk. Viņš jautā arī, kāpēc vēl jāiegulda 32 bitu Windows atbalstā. Lietotājs ar segvārdu Sacul vaicāja pēc atkāpšanās plāna gadījumam, ja metožu priekšgals izrādās lēnāks par pašreizējo. Mark Shannon, viens no JIT izstrādātājiem, iebilst pret pašu pulksteni: sešu mēnešu termiņš atstāj par maz laika kopienas apspriešanai. Salīdzinājumam pavedienā minēts PEP 703 par GIL izņemšanu, kuru padome vērtēja piecus mēnešus.
Brett Cannon PEP atbalsta un min divus punktus: 20 % mērķi versijai 3.17 un prasību, lai JIT strādā kopā ar bezGIL būvējumu. Vadības padome 6. augustā rīkoja atvērtās stundas ar PEP autoriem un pārbaudīja, vai dokuments atbild uz jautājumiem, ko padome bija uzdevusi jūnijā. Nākamā apspriešana bija ieplānota nedēļu vēlāk.
Ko tas maina lietotājiem
Līdz nākamajam attīstības ciklam gandrīz neko. Python 3.15 iznāk 1. oktobrī, izlaiduma vadītājs ir Hugo van Kemenade. JIT tajā paliek eksperimentāls un pēc noklusējuma izslēgts, tāpat kā 3.13 un 3.14 laidienos. Moratorijs skar cilvēkus, kas raksta JIT kodu. Tiem, kas Python vienkārši lieto, komandrindā nemainās nekas.
Pirmais pārbaudes punkts iestājas ar Python 3.16, kur jāparādās vismaz 5 % pieaugumam. LWN 1. septembrī vērtēja, ka darbs pie JIT visdrīzāk turpināsies, taču termiņš paliek neskaidrs. Ja PEP 836 līdz decembrim netiek pieņemts, JIT kods no CPython main zara tiek izņemts un attīstība pārceļas ārpus galvenā repozitorija.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.