Globaali tulkkilukko (GIL) näyttää olevan usein mainittu tärkeimpänä syynä sille, miksi ketjuttaminen ja vastaavat ovat haastavia Pythonissa – mikä herättää kysymyksen ”Miksi se tehtiin ensinnäkin?”
Koska en ole ohjelmoija, minulla ei ole aavistustakaan miksi se voisi olla – mikä oli GIL: n asettamisen logiikka?
Kommentit
- Wikipedia-artikkelissa todetaan, että ” GIL voi olla merkittävä este rinnakkaisuudelle – hinta, joka maksetaan kielen dynaamisuudesta ” , ja jatkaa, että ” Syitä tällaisen lukituksen käyttämiseen ovat: yksisäikeisten ohjelmien nopeus (ei tarvetta hankkia tai vapauttaa lukkoja kaikista tietorakenteista erikseen), ja C-kirjastojen helppo integrointi, jotka yleensä ovat ei langattomasti turvallinen. ”
- @RobertHarvey, dynaamisuudella ei ole mitään tekemistä sen kanssa. Ongelma on mutaatio.
- stackoverflow.com/questions/265687/…
- Eikö ’ voi auttaa tuntemaan, että kuten Java ’ ei ole allekirjoittamattomia numeroita, sen tarkoituksena oli estää ihmisiä, jotka eivät ’ eivät tiedä, mitä he ’ ampuvat itsensä jalkaan. Valitettavasti jokainen, joka tietää tietää, mitä ’ tekee, saa puutteellisen kielen, mikä on todellinen häpeä, koska Python rokkaa niin monella muulla tavalla
- @Basic on oltava jokin tavanomainen tapa käsitellä tavutaulukkoja Java-ohjelmassa (en ole käyttänyt sitä ’ en pitkään aikaan) salausmatematiikan tekemiseksi. Pythonilla (esimerkiksi) ei ’ t ole allekirjoitettuja numeroita, mutta en yritä ’ edes yrittää tehdä sen kanssa bittiä, koska siellä on parempia tapoja.
Vastaa
Pythonissa on useita toteutuksia, esimerkiksi CPython, IronPython, RPython, jne.
Joillakin heistä on GIL, joillakin ei. Esimerkiksi CPythonilla on GIL:
From http://en.wikipedia.org/wiki/Global_Interpreter_Lock
Ohjelmointikielillä GIL: llä kirjoitetut sovellukset voidaan suunnitella käyttämään erillisiä prosesseja täydellisen rinnakkaisuuden saavuttamiseksi, koska jokaisella prosessilla on oma tulkki ja puolestaan on oma GIL.
GIL: n edut
- Yksisäikeisten ohjelmien nopeus.
- Helppo integroida C-kirjastot, jotka eivät yleensä ole langattomia.
Miksi Python (CPython ja muut) käyttää GIL
CPythonissa yleinen tulkkilukko tai GIL on mutex, joka estää useita alkuperäisiä ketjuja suorittamasta Python-tavukoodeja kerralla. Tämä lukitus on välttämätön lähinnä siksi, että CPythonin muistinhallinta ei ole langattomaa.
GIL on kiistanalainen, koska se estää monisäikeisiä CPython-ohjelmia hyödyntämästä moniprosessorijärjestelmiä täysimääräisesti tietyissä tilanteissa. Huomaa, että mahdollisesti estäminen tai pitkään käynnissä olevat toiminnot, kuten I / O, kuvankäsittely ja NumPy-numeromurskaus, tapahtuvat GIL: n ulkopuolella.Siksi vain monisäikeisissä ohjelmissa, jotka viettävät paljon aikaa GIL: ssä tulkitsemalla CPython-tavukoodia, GIL: stä tulee pullonkaula.
Pythonilla on GIL toisin kuin hienorakeinen lukitus useista syistä:
-
Se on nopeampi yksisäikeisessä tapauksessa.
-
Se on nopeampaa monisäikeisessä tapauksessa i / o-sidotuissa ohjelmissa.
-
Se on nopeampaa monisäikeisessä tapauksessa prosessoreille sidotuissa ohjelmissa, jotka eivät heidän laskentatehokkaan työnsä C-kirjastoissa.
-
Se tekee C-laajennuksia on helpompi kirjoittaa: Python-ketjuja ei vaihdeta, paitsi missä annat sen tapahtua (ts. Py_BEGIN_ALLOW_THREADS- ja Py_END_ALLOW_THREADS-makrojen välillä).
-
Se helpottaa C-kirjastojen käärimistä. Sinun ei tarvitse huolehtia säikeiden turvallisuudesta. Jos kirjasto ei ole säiettä turvallinen, pidä GIL lukittuna, kun soitat sitä.
GIL voi Pythonin vakiokirjasto vapauttaa GIL: n jokaisen estävän i / o-puhelun ympärillä. Siksi GIL: llä ei ole vaikutusta i / o-sidottujen palvelimien suorituskykyyn. Voit siis luoda verkkopalvelimia Pythonissa prosesseilla (haarukka), säikeillä tai asynkronisilla i / o-tiedostoilla, jolloin GIL ei esty.
C: n tai Fortranin numeerisia kirjastoja voidaan kutsua vastaavasti GIL julkaistu. Kun C-laajennuksesi odottaa FFT: n valmistumista, tulkki suorittaa muita Python-ketjuja.GIL on siten myös tässä tapauksessa helpompaa ja nopeampaa kuin hienorakeinen lukitus. Tämä muodostaa suurimman osan numeerisesta työstä. NumPy-laajennus vapauttaa GIL: n aina kun se on mahdollista.
Langat ovat yleensä huono tapa kirjoittaa useimpia palvelinohjelmia. Jos kuorma on pieni, haarukointi on helpompaa. Jos kuorma on suuri, asynkroninen i / o- ja tapahtumavetoinen ohjelmointi (esim. Pythonin Twisted-kehyksen käyttö) on parempi. Ainoa tekosyy ketjujen käyttämiseen on os.forkin puute Windowsissa.
GIL on ongelma vain ja vain, jos teet prosessorivoimaa työtä puhtaassa Pythonissa. Täältä saat puhtaamman suunnittelun prosessien ja viestien välityksen avulla (esim. Mpi4py). Python-juustossa on myös ”käsittely” -moduuli shop, joka antaa prosesseille saman käyttöliittymän kuin säikeet (ts. korvaa threading.Thread käsittely.Processilla).
Lankoja voidaan käyttää ylläpitämään graafisen käyttöliittymän herkkyyttä GIL: stä riippumatta. Jos GIL heikentää suorituskykyäsi (vrt. yllä oleva keskustelu), voit antaa lankaasi synnyttää prosessin ja odottaa sen päättymistä.
Kommentit
- Kuulostaa hapan viinirypäleiltä Python ei voi ’ t tehdä ketjuja oikein, joten määrität syyt miksi ketjut ovat tarpeettomia tai jopa huonoja. ” Jos kuorma on matala, fo rking on helpompaa, ”, vakavasti? Ja GIL on ” nopeampi ” kaikissa näissä tapauksissa vain, jos vaadit viitteiden laskemisen GC: n käyttöä.
-
s/RPython/PyPy/g. @MichaelBorgwardt Syiden esittäminen pro GIL on eräänlainen kysymyksen asia, eikö ’ ole sitä? Vaikka olisin samaa mieltä siitä, että osa tämän vastauksen sisällöstä (nimittäin vaihtoehtojen keskustelu) on asian vieressä. Ja hyvässä tai pahassa, uudelleenlaskennasta on nyt melkein mahdotonta päästä eroon – se on syvään juurtunut koko sovellusliittymään ja koodipohjaan; ’ on melkein mahdotonta päästä eroon kirjoittamatta uudelleen puolta koodia ja rikkomatta kaikkia ulkoisia koodeja. - Don ’ älä unohda kirjastoa
multiprocessing– standardi 2.6 lähtien. Sen ’ työväenpoolit ovat erittäin liukas abstraktio joillekin yksinkertaisille rinnakkaisuustyypeille. - @alcalde Vain jos et ’ et tiedä mitä ’ tee ja / tai et ’ et halua, että ketjut pystyvät toimimaan yhteistyössä / kommunikoida. Muuten se ’ aiheuttaa kuninkaallista tuskaa takapuolella, varsinkin kun otetaan huomioon uuden prosessin käynnistämisen joissakin käyttöjärjestelmissä. Meillä on palvelimia, joissa on 32 ydintä, joten niiden täyteen hyödyntämiseen CPythonissa tarvitaan ’ d 32 prosessia. Että ’ ei ole ” hyvä ratkaisu ” se ’ sa hakkeroi kiertää CPythonin ’ puutteet.
- Sen, että ketjut ovat muilla alustoilla kuin Windows, pitäisi olla riittävä todiste siitä, että haarukka ’ ei riitä kaikissa tilanteissa.
Vastaa
Ensin off: Pythonilla ei ole GIL: ää. Python on ohjelmointikieli. Ohjelmointikieli on joukko abstrakteja matemaattisia sääntöjä ja rajoituksia. Python-kielimäärityksessä ei ole mitään, joka sanoo, että GIL: n on oltava.
Pythonissa on monia erilaisia toteutuksia. Joillakin on GIL, joillakin ei.
Yksi yksinkertainen selitys GIL: lle on, että samanaikaisen koodin kirjoittaminen on vaikeaa. Asettamalla jättiläinen lukko koodisi ympärille pakotat sen toimimaan aina sarjana. Ongelma ratkaistu!
Erityisesti CPythonissa yksi tärkeä tavoite on helpottaa tulkin laajentamista C: llä kirjoitetuilla laajennuksilla. Jälleen samanaikaisen koodin kirjoittaminen on vaikeaa, joten takaamalla, että ei tule samanaikaisuus, se helpottaa tulkkien laajennusten kirjoittamista. Lisäksi monet näistä laajennuksista ovat vain ohuita kääreitä olemassa olevien kirjastojen ympärille, joita ei ehkä ole kirjoitettu samanaikaisesti.
Kommentit
- Että ’ s sama argumentti kuin Java ’ s, jos puuttuu allekirjoittamattomia numeerisia tyyppejä – kehittäjien mielestä kaikki muut ovat tyhmempiä kuin he ovat …
- @Basic – uskokaa tai älkää, vaikka olisit ’ et oikeastaan, todella tyhmä, käy ilmi, että jos sinulla on kieli, joka tekee yksinkertaistavia oletuksia, jotka merkitsevät et ’ ajattele tiettyjä asioita, jotta ne toimisivat, on silti hyödyllinen asia.CPython soveltuu erinomaisesti tiettyihin asioihin, mukaan lukien yksinkertaiset monisäikeiset sovellukset (joissa ohjelma on IO-sidottu, mikä on monia, ja siksi GIL: llä ei ole merkitystä ’), koska suunnittelupäätökset paras ratkaisu GIL helpottaa myös näiden sovellusten ohjelmointia, erityisesti sitä, että se tukee atomioperaatioita kokoelmissa .
- @Jules Kyllä, se ’ on erittäin kätevä, kunnes tarvitset näitä ominaisuuksia. cpython ’ s ” ensisijainen ” ratkaisu ” kirjoita se vain toisella kielellä, kuten c ++ ” tarkoittaa, että menetät kaikki python-edut. Jos ’ kirjoitat puolet koodistasi c ++, miksi aloitat Pythonista? Toki pienille API- / liimaprojekteille ’ on nopeaa ja helppoa, ja ETL: lle se on ’ vertaansa vailla, mutta se ’ eivät sovellu mihinkään, mikä vaatii raskasta nostoa. Sama kuin Java-yhteyden käyttäminen laitteistoon … Se ’ melkein koominen kehät, joiden läpi sinun täytyy hypätä.
- @Basic Yksi Pythonista ’ s ja siten CPythonin ’ ydinfilosofioiden laajentaminen on tehdä tekniikasta ” ystävällinen ja helppo käyttää ”. Rinnakkainen ohjelmointi ilman yleistä lukitusta ei ole sitä. Ottaen huomioon, että on olemassa monia toteutuksia ilman GIL: ää, on järkevää tarjota ainakin yksi toteutus, jolla on se.
- Sanot ” on järkevää ainakin tarjota yksi toteutus, jolla on se. ” kuten ’ on ilmeinen johtopäätös, mutta ei muuta kieltä
olen tietoinen kehittäjien harrastamisesta tällä tavalla, joten se ei voi ’ olla että ilmeinen.
vastaus
Mikä on GIL: n tarkoitus?
CAPI-dokumentaatiossa on sanottava asiasta:
Python-tulkki ei ole täysin säikeetön . Monisäikeisten Python-ohjelmien tukemiseksi on olemassa maailmanlaajuinen lukitus, nimeltään yleinen tulkin lukko tai GIL, jota nykyisen säikeen on pidettävä, ennen kuin se pääsee käsiksi Python-objektiin. Ilman lukitusta yksinkertaisimmatkin toiminnot saattavat aiheuttaa ongelmia monisäikeisessä ohjelmassa: esimerkiksi kun kaksi säiettä lisää samanaikaisesti saman objektin viitemäärää, viitemäärää saatetaan kasvattaa vain kerran kahden sijasta.
Toisin sanoen, GIL estää valtioiden korruptiota. Python-ohjelmien ei pitäisi koskaan tuottaa segmentointivirhettä, koska vain muistin turvalliset toiminnot ovat sallittuja. GIL laajentaa tämän varmuuden monisäikeisiin ohjelmiin.
Mitkä ovat vaihtoehdot?
Jos GIL: n tarkoituksena on suojata valtiota korruptiolta, yksi ilmeinen vaihtoehto on lukko paljon hienommalle viljalle; kenties objektitasolla. Tämän ongelmana on, että vaikka sen on osoitettu lisäävän monisäikeisten ohjelmien suorituskykyä, sillä on enemmän yleiskustannuksia ja sen seurauksena kärsivät yksisäikeiset ohjelmat.
Kommentit
- Olisi hienoa antaa käyttäjän suorittaa ohjelma tulkkivaihtoehdolla, joka korvaa gilin hienorakeisella lukolla, ja tietää jotenkin – vain luettavalla tavalla – onko nykyinen prosessi nostettu vai ei gil.
- GIL: stä huolimatta onnistuin tuottamaan segmentointivirheen monisäikeisessä ohjelmassa pyodbc-moduulin huolimattomasta käytöstä. Täten ” ei saa koskaan tuottaa segmentointivirhettä ” on virhe.