Pre všetky skvelé a pohodlné funkcie Pythonu zostáva jeden cieľ nedosiahnuteľný: aplikácie Pythonu bežiace na referenčnom tlmočníkovi CPython a paralelne využívajúce viac jadier CPU.
Toto je už dlho jedným z najväčších kameňov úrazu Pythonu, najmä preto, že všetky riešenia sú nemotorné. Naliehavosť hľadania dlhodobého riešenia problému rastie, najmä keď sa počet jadier procesorov neustále zvyšuje (viď 24-jadrový behemoth spoločnosti Intel).
Jeden zámok za všetky
V skutočnosti je možné použiť vlákna v aplikáciách Pythonu - už ich existuje veľa. Čo jenie je možné, aby CPython spúšťal viacvláknové aplikácie pri každom vykonaní každého vlákna paralelne na inom jadre. Správa vnútornej pamäte CPython nie je bezpečná pre vlákna, takže tlmočník spúšťa naraz iba jedno vlákno, podľa potreby medzi nimi prepína a kontroluje prístup do globálneho stavu.
Tento uzamykací mechanizmus, Global Interpreter Lock (GIL), je jediným najväčším dôvodom, prečo CPython nemôže spúšťať vlákna paralelne. Existuje niekoľko poľahčujúcich faktorov; napríklad I / O operácie ako čítanie disku alebo siete nie sú viazané na GIL, takže môžu bežať voľne vo svojich vlastných vláknach. Ale čokoľvek viacvláknové aj s CPU viazané je problém.
Pre programátorov v jazyku Python to znamená, že ťažké výpočtové úlohy, ktoré majú úžitok z rozloženia na viac jadier, nefungujú dobre, čo vylučuje použitie externej knižnice. Pohodlie práce v Pythone prináša veľké náklady na výkon, ktoré je čoraz ťažšie prehltnúť, pretože do popredia sa dostávajú rýchlejšie a rovnako pohodlné jazyky, ako je Google Go.
Vyberte zámok
Postupom času sa objavilo množstvo možností, ktoré zlepšujú - ale nevylučujú - limity GIL. Jednou zo štandardných taktík je spustenie viacerých inštancií CPythonu a zdieľanie kontextu a stavu medzi nimi; každá inštancia beží nezávisle na druhej v samostatnom procese. Ale ako vysvetľuje Jeff Knupp, zisky poskytované paralelným fungovaním môžu byť stratené úsilím potrebným na zdieľanie stavu, takže táto technika je najvhodnejšia pre dlhodobé operácie, ktoré združujú svoje výsledky v priebehu času.
Rozšírenia C nie sú viazané na GIL, takže toľko knižníc pre Python, ktoré potrebujú rýchlosť (napríklad knižnica matematiky a štatistík Numpy), môže bežať na viacerých jadrách. Obmedzenia v samotnom CPythone však zostávajú. Ak sa najlepším spôsobom, ako sa vyhnúť GIL, je použitie C, bude to viesť k tomu, že viac programátorov bude odchádzať od Pythonu k C.
PyPy, verzia Pythonu, ktorá kompiluje kód prostredníctvom JIT, sa nezbaví GIL, ale vynahradí si to jednoduchým rýchlejším spustením kódu. V niektorých ohľadoch to nie je zlá náhrada: Ak je hlavným dôvodom rýchlosti sledovania multithreadingu rýchlosť, môže byť PyPy schopný poskytnúť rýchlosť bez komplikácií multithreadingu.
Nakoniec bol samotný GIL v Pythone 3 trochu prepracovaný, s lepšou obsluhou prepínania vlákien. Všetky jeho základné predpoklady - a obmedzenia - však zostávajú. Stále existuje GIL a stále drží konania.
Žiadny GIL? Žiaden problém
Napriek tomu všetkému pokračuje hľadanie Pythonu bez GIL kompatibilného s existujúcimi aplikáciami. Ostatné implementácie Pythonu úplne skončili s GIL, ale za cenu. Napríklad Jython beží nad JVM a namiesto GIL používa systém sledovania objektov JVM. Rovnaký prístup má IronPython aj prostredníctvom CLR spoločnosti Microsoft. Ale obaja trpia nekonzistentným výkonom a niekedy bežia oveľa pomalšie ako CPython. Tiež nemôžu ľahko komunikovať s externým kódom C, takže veľa existujúcich aplikácií v jazyku Python nebude fungovať.
Projekt PyParallel, ktorý vytvoril Trent Nelson zo spoločnosti Continuum Analytics, je „experimentálnou vidlicou typu proof-of-concept pre Python 3 určenou na optimálne využitie viacerých jadier CPU.“ Neodstraňuje GIL, ale zmierňuje jeho dopad nahradením async modul, teda aplikácie, ktoré používajúasync pre paralelizmus (napríklad viacvláknové I / O ako webový server) má najväčší úžitok. Tento projekt bol pozastavený už niekoľko mesiacov, ale jeho dokumentácia uvádza, že jeho vývojári majú čas venovať sa tomu, aby ho napravili, takže ho možno nakoniec zahrnúť do programu CPython: „Na tom, čo idete, nie je nič zlé na pomalom a rovnomernom postupe. správnym smerom. ““
Jedným z dlhoročných projektov tvorcov PyPy bola verzia Pythonu, ktorá využíva techniku nazývanú „softvérová transakčná pamäť“ (PyPy-STM). Výhodou podľa tvorcov PyPy je „môžete mierne vylepšiť svoje existujúce programy bez viacerých vlákien a prinútiť ich, aby používali viac jadier“.
PyPy-STM znie ako kúzlo, ale má dve nevýhody. Po prvé, ide o nedokončenú výrobu, ktorá momentálne podporuje iba Python 2.x, a po druhé, stále vyžaduje výkonnostný test aplikácií bežiacich na jednom jadre. Pretože jednou z podmienok citovaných tvorcom Pythonu Guidom van Rossumom pre akékoľvek pokusy o odstránenie GIL z CPythonu je, že jeho nahradenie by nemalo znížiť výkonnosť pre jednojadrové aplikácie s jedným vláknom, takáto oprava v CPythone nepríde v súčasnom stave.
Poponáhľajte sa a počkajte
Larry Hastings, hlavný vývojár Pythonu, sa na PyCone 2016 podelil so svojimi názormi na to, ako je možné odstrániť GIL. Hastings zdokumentoval svoje pokusy o odstránenie GIL a skončil tak s verziou Pythonu, ktorá nemala GIL, ale trpela agonizujúco pomaly kvôli neustálym chybám v cache.
Môžete stratiť GIL, zhrnul Hastings, ale musíte mať nejaký spôsob, ako zaručiť, že globálne objekty upravuje iba jedno vlákno naraz - napríklad tak, že takéto zmeny stavu zvládne vyhradené vlákno v tlmočníkovi.
Jednou z dlhodobých dobrých správ je, že ak CPython zbaví GIL, vývojári používajúci tento jazyk už budú pripravení využívať multithreading. Mnoho zmien sa teraz zapracovalo do syntaxe Pythonu, napríklad fronty a async/čakať kľúčové slová pre Python 3.5, umožňujú ľahké rozdelenie úloh medzi jadrá na vysokej úrovni.
Množstvo práce potrebné na to, aby bol Python bez GIL menej, ale zaručuje, že sa najskôr zobrazí v samostatnej implementácii, ako je PyPy-STM. Tí, ktorí si chcú vyskúšať systém bez GIL, to môžu urobiť pomocou takéhoto úsilia tretej strany, ale pôvodný CPython zostane nateraz pravdepodobne nedotknutý. Dúfame, že čakanie už nebude oveľa dlhšie.
