Nepaisant visų puikių ir patogių „Python“ funkcijų, nepasiekiamas vienas tikslas: „Python“ programos, veikiančios „CPython“ etaloniniu vertėju ir lygiagrečiai naudojančios kelis procesoriaus branduolius.
Tai jau seniai yra vienas didžiausių „Python“ kliūčių, ypač todėl, kad visi būdai yra nerangūs. Skubumas rasti ilgalaikį šios problemos sprendimą vis labiau auga, visų pirma, kai ir toliau auga procesorių skaičius (žr. „Intel“ 24 branduolių elgesį).
Viena spyna visiems
Tiesą sakant, „Python“ programose galima naudoti gijas - daugelis jų jau naudojasi. Kasne CPython gali paleisti daugiasrieges programas su kiekviena gija lygiagrečiai ant kitos šerdies. „CPython“ vidinės atminties valdymas nėra saugus gijoms, todėl vertėjas vienu metu paleidžia tik vieną giją, prireikus persijungia tarp jų ir kontroliuoja prieigą prie pasaulinės būsenos.
Šis užrakinimo mechanizmas, „Global Interpreter Lock“ (GIL), yra vienintelė didžiausia priežastis, kodėl „CPython“ negali paleisti gijų lygiagrečiai. Yra keletas lengvinančių veiksnių; pavyzdžiui, įvesties / išvesties operacijos, pvz., disko ar tinklo skaitymai, nėra susaistytos GIL, todėl jos gali laisvai veikti savo gijose. Tačiau viskas, kas yra daugialypė ir susieta su procesoriumi, yra problema.
„Python“ programuotojams tai reiškia, kad sunkios skaičiavimo užduotys, kurioms naudinga būti paskirstytoms keliuose branduoliuose, neveikia gerai, todėl draudžiama naudoti išorinę biblioteką. Patogus darbas „Python“ kainuoja dideles našumo sąnaudas, kurias vis sunkiau praryti, nes išryškėja greitesnės, vienodai patogios kalbos, tokios kaip „Google“ Go.
Pasirinkite spyną
Laikui bėgant atsirado daugybė variantų, kurie palengvina GIL ribas, tačiau jų nepanaikina. Viena standartinė taktika yra paleisti kelis „CPython“ egzempliorius ir dalytis tarp jų kontekstu bei būsena; kiekviena instancija veikia nepriklausomai nuo kitos atskirame procese. Tačiau, kaip paaiškina Jeffas Knuppas, lygiagrečiai bėgant gautą naudą galima prarasti pastangomis, reikalingomis dalytis būsena, todėl ši technika geriausiai tinka ilgai trunkančioms operacijoms, kurios laiko rezultatus sujungia.
C plėtinių GIL nesaisto, todėl daugelis „Python“ bibliotekų, kurioms reikalingas greitis (pvz., „Numpy“ matematikos ir statistikos biblioteka), gali veikti keliose šerdyse. Tačiau „CPython“ apribojimai išlieka. Jei geriausias būdas išvengti GIL yra naudoti C, tai atves daugiau programuotojų nuo Python ir link C.
„PyPy“, „Python“ versija, kurianti kodą per JIT, neatsikrato GIL, tačiau ją kompensuoja paprasčiausiai paleidus kodą greičiau. Tam tikru požiūriu tai nėra blogas pakaitalas: jei greitis yra pagrindinė priežastis, dėl kurios žiūrite į daugiasluoksnį gijimą, „PyPy“ gali suteikti greitį be sudėtinių gijų komplikacijų.
Galiausiai, pats GIL buvo šiek tiek perdarytas „Python 3“ su geresniu siūlų perjungimo valdikliu. Tačiau visos pagrindinės prielaidos ir apribojimai išlieka. Vis dar yra GIL, ir jis vis dar sulaiko procesą.
Nėra GIL? Jokiu problemu
Nepaisant viso to, toliau ieškoma „Python“ be GIL, suderinamo su esamomis programomis. Kiti „Python“ diegimai visiškai panaikino GIL, tačiau tai kainavo. Pavyzdžiui, „Jython“ veikia virš JVM ir vietoj GIL naudoja JVM objektų stebėjimo sistemą. „IronPython“ taiko tą patį požiūrį per „Microsoft“ CLR. Bet abu kenčia nuo nenuoseklių veikimo būdų, ir kartais jie veikia daug lėčiau nei „CPython“. Jie taip pat negali lengvai susieti su išoriniu C kodu, todėl daugelis esamų „Python“ programų neveiks.
Trento Nelsono iš „Continuum Analytics“ sukurtas projektas „PyParallel“ yra „eksperimentinė, koncepciją patvirtinanti„ Python 3 “šakutė, skirta optimaliai išnaudoti kelias procesoriaus šerdis“. Jis nepašalina GIL, tačiau pagerina jo poveikį pakeisdamas asinchroninis modulis, taigi programos, kurios naudojaasinchroninis lygiagretumas (pvz., daugialypis I / O kaip interneto serveris) turi didžiausią naudą. Projektas buvo neveikiantis kelis mėnesius, tačiau jo dokumentuose teigiama, kad jo kūrėjai gali neskubėdami skirti laiko, kad jis būtų teisingas, todėl galiausiai jis gali būti įtrauktas į „CPython“: „Lėtai ir stabiliai nėra nieko blogo, kol eini teisinga linkme “.
Vienas iš ilgalaikių „PyPy“ kūrėjų projektų buvo „Python“ versija, naudojanti techniką, vadinamą „programine operacine atmintimi“ (PyPy-STM). Pasak „PyPy“ kūrėjų, pranašumas yra tas, kad „jūs galite šiek tiek pakoreguoti savo esamas, be daugybės temų programas ir priversti jas naudoti kelis branduolius“.
„PyPy-STM“ skamba kaip magija, tačiau turi du trūkumus. Pirma, tai nebaigtas darbas, kuris šiuo metu palaiko tik „Python 2.x“, ir, antra, vis tiek reikalingas našumas toms programoms, kurios veikia viename branduolyje. Kadangi viena iš „Python“ kūrėjo Guido van Rossumo nurodytų nuostatų dėl bet kokių bandymų pašalinti GIL iš „CPython“ yra tai, kad jo pakeitimas neturėtų pabloginti vieno branduolio, vienos gijos programų našumo, toks pataisymas nenusileis „CPython“ dabartinėje būsenoje.
Paskubėk ir palauk
Larry Hastingsas, pagrindinis „Python“ kūrėjas, „PyCon 2016“ pasidalijo kai kuriomis savo nuomonėmis apie tai, kaip būtų galima pašalinti GIL. Hastingsas dokumentavo savo bandymus pašalinti GIL ir tai padarė „Python“ versija, kuri neturėjo GIL, tačiau veikė agoniškai lėtai dėl nuolatinių talpyklos praleidimų.
Galite prarasti GIL, apibendrindamas Hastingsą, tačiau turite turėti tam tikrą būdą, kaip garantuoti, kad tik viena gija vienu metu modifikuoja globalius objektus, pavyzdžiui, turint specialų siūlą vertėjui, kuris valdo tokius būsenos pokyčius.
Viena ilgalaikių gerų naujienų yra ta, kad jei ir kai „CPython“ išmes GIL, kalbą naudojantys kūrėjai jau bus pasirengę išnaudoti daugialypį gijimą. Dabar daugelis Python sintaksės pakeitimų, pvz., Eilės ir asinchroninis/laukti raktiniai žodžiai, skirti „Python 3.5“, palengvina aukšto lygio užduočių paskirstymą tarp branduolių.
Vis tiek darbo, reikalingo norint, kad „Python GIL“ būtų mažiau, tačiau garantuojama, kad jis pirmiausia pasirodys atskirame įgyvendinime, pvz., „PyPy-STM“. Tie, kurie nori išbandyti sistemą, neturinčią GIL, gali tai padaryti naudodamiesi tokiomis trečiųjų šalių pastangomis, tačiau tikriausiai kol kas originalus „CPython“ liks nepaliestas. Tikimės, kad laukti nereikia daug ilgiau.
