I Python diskuterer de allerede forslaget om å fjerne GIL og få bedre ytelse

Python-logo

Python er et programmeringsspråk på høyt nivå.

Nyheten kom nylig om at Python Project Steering Committee har kunngjort sitt ønske om å godkjenne Python-språkutvidelsesforslag «PEP-0703", noe som gjør den globale tolkelåsen valgfri i CPython og som i utgangspunktet definerer innbyggingen av CPython-kompileringsmodus uten Global Interpreter Lock (GIL).

PEP-0703 definerer å slutte å bruke GIL som standard, men legg til byggealternativet "–sin-gil" for å deaktivere det. Hvordan har du detl Den nye modusen forventes å løse problemet med parallellisering av operasjoner på flerkjernesystemer, forårsaket av det faktum at den globale låsen ikke tillater parallell tilgang til delte objekter fra forskjellige tråder.

Det nevnes at på lang sikt (etter 5 år), shell er planlagt endret som standard til bare i global ikke-låsende modus, samtidig som man dropper støtte for kompilering med GIL.

Takk alle sammen for at dere svarte på undersøkelsen om no-GIL-forslaget. Det er tydelig at den generelle følelsen er positiv, både for den generelle ideen og for PEP 703 spesielt. Styret er også stort sett positive til begge. Vi har til hensikt å akseptere PEP 703, selv om vi fortsatt jobber med detaljene for aksept.

Som vi har gjort noen ganger tidligere, ønsker vi å kommunisere vår intensjon om å akseptere PEP sammen med vår nåværende tenkning om detaljene knyttet til aksept.

Bortsett fra det, Det nevnes at endringene som planlegges gjennomført i tre trinn, som er kort, mellomlang og lang sikt. Gitt at i det første trinnet er det upraktisk å deaktivere GIL som standard på grunn av overhead forbundet med endringer i søppelsamleren, minnestyringssystemet og primitivene for organisering av låser. For eksempel, på grunn av bruken av referansetelling for trådisolering, er det et ytelsesfall for entrådede skript (i pyperformance-testpakken med 10%). Samtidig kan det være nødvendig å deaktivere GIL i vitenskapelig databehandling, der mangelen på parallellisering er et mer alvorlig problem enn den lineære hastigheten på kodeutførelse.

I det andre trinnet avventes i utgangspunktet bekreftelsen. og at det er tilstrekkelig støtte fra fellesskapet slik at bruken av "ikke-GIL er levedyktig" og sørg for at GIL-less build støttes, men ikke standard.

I den siste fasen vil no-GIL allerede være standardverdien og eventuelle rester av GIL vil bli fjernet (uten unødvendig å bryte bakoverkompatibiliteten).

Det observeres at arbeidet med å flytte bort fra GIL vil bli gjort meget nøye for ikke å gjenta feilen hva som skjedde ved promotering Python 3: En ikke-GIL-bygg må sikre kompatibilitet med eldre versjoner av Python, og eventuelle tredjeparts kodeendringer som kreves for å fungere på ikke-GIL-bygg, bør også fungere på GIL-bygg.

Det er ingen planer om å omnummerere versjonene til Python 4 for ikke-GIL-bygg, da de vil opprettholde ABI-kompatibilitet.

Gjennom hele prosessen vil vi (kjerneutviklerne, ikke bare SC) måtte revurdere fremdriften og foreslåtte tidslinjer. Vi ønsker ikke at dette skal bli nok en ti år lang bakoverkompatibilitetskamp, ​​og vi ønsker å kunne kansellere PEP 703 og finne en annen løsning hvis det ser ut til å bli problematisk, så vi må jevnlig sjekke at fortsatt arbeid er verdt det.

Vi håper dette gir en viss klarhet om fremtiden til PEP når vi utarbeider de nøyaktige detaljene for aksept. SC vil arbeide for å fullføre aksepten i løpet av de kommende ukene.

Før den fulle overgangen til ikke-GIL-bygg, planlegger vi å oppnå full fellesskapsstøtte for disse byggene, i tillegg til å tilby ytterligere C APIer og Python APIer for å muliggjøre sikker multithreading i eksisterende kode.

Til slutt, som allerede nevnt, forventes det at overgangen til tredje trinn kan skje om minst 5 år, og den sannsynlige datoen for PEP-0703 er utgivelsen av Python 3.13, planlagt til neste høst.

Lur interessert i å vite mer om det, kan du sjekke detaljene I den følgende lenken.


Legg igjen kommentaren

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *

*

*

  1. Ansvarlig for dataene: Miguel Ángel Gatón
  2. Formålet med dataene: Kontroller SPAM, kommentaradministrasjon.
  3. Legitimering: Ditt samtykke
  4. Kommunikasjon av dataene: Dataene vil ikke bli kommunisert til tredjeparter bortsett fra ved juridisk forpliktelse.
  5. Datalagring: Database vert for Occentus Networks (EU)
  6. Rettigheter: Når som helst kan du begrense, gjenopprette og slette informasjonen din.