Attiecībā uz visām lieliskajām un ērtajām Python funkcijām viens mērķis paliek nepieejams: Python lietotnes, kas darbojas uz CPython atsauces tulka un paralēli izmanto vairākus CPU kodolus.
Tas jau sen ir bijis viens no lielākajiem Python klupšanas akmeņiem, it īpaši tāpēc, ka visi risinājumi ir neveikli. Steidzamība rast ilgtermiņa risinājumu šim jautājumam pieaug, jo īpaši, jo turpina pieaugt procesoru pamatskaitlis (sk. Intel 24 kodolu behemotu).
Viena slēdzene visiem
Patiesībā pavedienus ir iespējams izmantot Python lietojumprogrammās - daudzi no tiem jau to dara. Kasnē CPython ir iespējams palaist daudzšķiedru lietojumprogrammas ar katru pavedienu paralēli uz cita kodola. CPython iekšējās atmiņas pārvaldība nav droša ar pavedieniem, tāpēc tulks vienlaikus palaiž tikai vienu pavedienu, pēc vajadzības pārslēdzoties starp tiem un kontrolējot piekļuvi globālajam stāvoklim.
Šis bloķēšanas mehānisms - Global Interpreter Lock (GIL) ir vienīgais lielākais iemesls, kāpēc CPython nevar palaist pavedienus paralēli. Ir daži atbildību mīkstinoši faktori; piemēram, I / O operācijām, piemēram, diska vai tīkla lasījumiem, GIL nav saistošs, tāpēc tās var brīvi palaist savās pavedienos. Bet viss, kas ir gan daudzšķiedru, gan saistīts ar procesoru, ir problēma.
Python programmētājiem tas nozīmē, ka smagie skaitļošanas uzdevumi, kas gūst labumu no sadalīšanas pa vairākiem kodoliem, nedarbojas labi, liedzot izmantot ārēju bibliotēku. Ērtai darbībai Python ir vajadzīgas lielas veiktspējas izmaksas, kuras kļūst grūtāk norīt, jo priekšplānā izvirzās ātrākas, tikpat ērtas valodas kā Google's Go.
Izvēlieties slēdzeni
Laika gaitā ir parādījusies virkne iespēju, kas uzlabo GIL robežas, bet tās nenovērš. Viena standarta taktika ir palaist vairākus CPython gadījumus un koplietot kontekstu un stāvokli starp tiem; katrs gadījums darbojas neatkarīgi no otra atsevišķā procesā. Bet, kā paskaidro Džefs Knups, ieguvumus, kas rodas, darbojoties paralēli, var zaudēt pūles, kas vajadzīgas, lai kopīgotu stāvokli, tāpēc šī metode ir vislabāk piemērota ilgstošām operācijām, kas laika gaitā apkopo savus rezultātus.
C paplašinājumiem GIL nav saistošs, tāpēc daudzas Python bibliotēkas, kurām nepieciešams ātrums (piemēram, math-stats bibliotēka Numpy), var darboties vairākos kodolos. Bet pašā CPython ierobežojumi paliek. Ja labākais veids, kā izvairīties no GIL, ir izmantot C, tas vairāk programmētāju aizdzīs no Python un virzienā uz C.
PyPy, Python versija, kas apkopo kodu, izmantojot JIT, neatbrīvojas no GIL, bet to kompensē, vienkārši palaižot kodu ātrāk. Dažos veidos tas nav slikts aizstājējs: ja ātrums ir galvenais iemesls, kāpēc jūs esat skatījies uz daudzsavienojumu, PyPy, iespējams, spēs nodrošināt ātrumu bez sarežģījumiem, kas saistīti ar daudzsavienojumu.
Visbeidzot, pats GIL tika nedaudz pārveidots Python 3, izmantojot labāku vītnes pārslēgšanas apdarinātāju. Bet visi tā pamatā esošie pieņēmumi - un ierobežojumi - paliek. Joprojām ir GIL, un tas joprojām kavē procesu.
Nav GIL? Nekādu problēmu
Neskatoties uz to visu, tiek turpināts meklējums pēc GIL bez Python, kas būtu saderīgs ar esošajām lietojumprogrammām. Citas Python ieviešanas ir pilnībā atcēlušas GIL, taču par maksu. Piemēram, Jython darbojas virs JVM un GIL vietā izmanto JVM objektu izsekošanas sistēmu. IronPython izmanto tādu pašu pieeju, izmantojot Microsoft CLR. Bet abi cieš no nekonsekventas veiktspējas, un dažreiz tie darbojas daudz lēnāk nekā CPython. Viņi arī nevar viegli saskarni ar ārējo C kodu, tāpēc daudzas esošās Python lietojumprogrammas nedarbosies.
Trent Nelson, Continuum Analytics izveidots projekts PyParallel ir "eksperimentāls, konceptuāls Python 3 dakša, kas paredzēts, lai optimāli izmantotu vairākus CPU kodolus". Tas nenoņem GIL, bet uzlabo tā ietekmi, aizstājot asinhronais modulis, tātad lietotnes, kas izmantoasinhronais paralēlisms (piemēram, daudzšķiedru I / O, piemēram, tīmekļa serveris) visvairāk gūst labumu. Projekts ir neaktivizējies vairākus mēnešus, taču tā dokumentācijā ir teikts, ka tā izstrādātājiem ir ērti veltīt laiku, lai to panāktu pareizi, tāpēc to galu galā var iekļaut CPython: "Lēnām un vienmērīgi nav nekas nepareizs, kamēr dodaties pareizajā virzienā. "
Viens ilgstošs PyPy veidotāju projekts ir bijusi Python versija, kurā tiek izmantota tehnika, ko sauc par "programmatūras transakciju atmiņu" (PyPy-STM). Priekšrocība, pēc PyPy veidotāju domām, ir "jūs varat veikt nelielus pielāgojumus savām esošajām programmām, kas nav multitreaded, un likt tām izmantot vairākus kodolus".
PyPy-STM izklausās pēc maģijas, taču tai ir divi trūkumi. Pirmkārt, tas ir nepabeigts darbs, kas pašlaik atbalsta tikai Python 2.x, un, otrkārt, tas joprojām prasa veiktspējas rezultātu lietojumprogrammām, kas darbojas vienā kodolā. Tā kā viens no nosacījumiem, uz kuru atsaucas Python veidotājs Gvido van Rossums par jebkādiem mēģinājumiem noņemt GIL no CPython, ir tāds, ka tā aizstāšana nedrīkst pasliktināt viena kodola, viena pavediena lietojumprogrammu veiktspēju, šāds labojums nenonāk CPython pašreizējā stāvoklī.
Pasteidzieties un pagaidiet
Larijs Hastings, galvenais Python izstrādātājs, PyCon 2016 dalījās ar dažiem saviem uzskatiem par to, kā GIL varētu noņemt. Hastings dokumentēja savus mēģinājumus noņemt GIL un, to darot, beidzās ar Python versiju, kurai nebija GIL, bet kas pastāvīgi kešatmiņas kļūdu dēļ darbojās mokoši lēni.
Jūs varat zaudēt GIL, rezumējot Hastings, taču jums ir jābūt zināmam veidam, kā garantēt, ka tikai viens pavediens vienlaikus modificē globālos objektus, piemēram, tulkotājā ir īpašs pavediens, kas apstrādā šādas stāvokļa izmaiņas.
Viena no ilgtermiņa labajām ziņām ir tā, ka tad, kad un kad CPython atbrīvo GIL, izstrādātājiem, kas lieto valodu, jau tiks sagatavots, lai izmantotu daudzsavienojumu. Daudzas izmaiņas tagad ir iekļautas Python sintaksē, piemēram, rindas un asinhronais/gaidi Python 3.5 atslēgvārdi, ļauj ērti sadalīt uzdevumus starp kodoliem augstā līmenī.
Tomēr darba apjoms, kas nepieciešams, lai Python GIL būtu mazāks, bet garantē, ka tas vispirms parādīsies atsevišķā ieviešanā, piemēram, PyPy-STM. Tie, kas vēlas izmēģināt sistēmu bez GIL, to var izdarīt, izmantojot šādas trešās puses centienus, taču sākotnējais CPython, visticamāk, pagaidām paliks neskarts. Šeit ir cerība, ka gaidīšana nav daudz ilgāka.
