In Python discutono già della proposta di rimuovere GIL e ottenere prestazioni migliori

Recentemente è arrivata la notizia che il Il comitato direttivo del progetto Python ha annunciato la volontà di approvare il Proposta di estensione del linguaggio Python «PEP-0703″, rendendo facoltativo il blocco dell'interprete globale in CPython e che sostanzialmente definisce l'incorporamento della modalità di compilazione CPython senza Global Interpreter Lock (GIL).

PEP-0703 definisce di smettere di usare GIL per impostazione predefinita, ma aggiungi l'opzione di compilazione "–sin-gil" per disabilitarla. Come stail La nuova modalità dovrebbe risolvere il problema con la parallelizzazione di operazioni su sistemi multi-core, causato dal fatto che il blocco globale non consente l'accesso parallelo a oggetti condivisi da thread diversi.

Si dice che a lungo termine (dopo 5 anni), shell è pianificato per essere modificato per impostazione predefinita solo in modalità globale non bloccante, eliminando allo stesso tempo il supporto per la compilazione con GIL.

Grazie a tutti per aver risposto al sondaggio sulla proposta no-GIL. È chiaro che il sentimento generale è positivo, sia per l'idea generale che per il PEP 703 in particolare. Anche il Consiglio di amministrazione è ampiamente positivo su entrambi. Intendiamo accettare PEP 703, anche se stiamo ancora elaborando i dettagli dell'accettazione.

Come abbiamo fatto alcune volte in passato, vogliamo comunicare la nostra intenzione di accettare il PEP insieme al nostro pensiero attuale sui dettagli relativi all'accettazione.

A parte quello, Si dice che le modifiche che dovrebbero essere effettuate in tre fasi, che sono a breve, medio e lungo termine. Dato che nella prima fase, disabilitare GIL per impostazione predefinita non è pratico a causa del sovraccarico associato alle modifiche al Garbage Collector, al sistema di gestione della memoria e alle primitive per l'organizzazione dei blocchi. Ad esempio, a causa dell'uso del conteggio dei riferimenti per l'isolamento dei thread, si verifica un calo delle prestazioni per gli script a thread singolo (nella suite di test pyperformance del 10%). Allo stesso tempo, potrebbe essere necessario disabilitare il GIL nel calcolo scientifico, per il quale la mancanza di parallelizzazione è un problema più grave della velocità lineare di esecuzione del codice.

Nella seconda fase, sostanzialmente, si attenderà la conferma. e che ci sia un sostegno sufficiente da parte della comunità in modo che l'uso di "non GIL è fattibile" e assicurati che la build senza GIL sia supportata ma non predefinita.

Nell'ultima fase, no-GIL sarà già il valore predefinito e qualsiasi traccia di GIL verrà rimossa (senza rompere inutilmente la compatibilità con le versioni precedenti).

Si osserva che il lavoro per allontanarsi da GIL sarà fatto con molta attenzione per non ripetere l'errore cosa è successo durante la promozione Python 3: una build non GIL dovrà garantire la compatibilità con le versioni precedenti di Python e qualsiasi modifica al codice di terze parti richiesta per funzionare su build non GIL dovrebbe funzionare anche su build GIL.

Non ci sono piani per rinumerare le versioni in Python 4 per build non GIL, poiché manterranno la compatibilità ABI.

Durante tutto il processo, noi (gli sviluppatori principali, non solo l'SC) dovremo rivalutare i progressi e le tempistiche suggerite. Non vogliamo che questa diventi un'altra lotta decennale per la compatibilità con le versioni precedenti e vogliamo essere in grado di annullare PEP 703 e trovare un'altra soluzione se sembra diventare problematico, quindi dobbiamo controllare regolarmente che valga la pena continuare a lavorare.

Ci auguriamo che questo fornisca un po' di chiarezza sul futuro del PEP mentre elaboriamo i dettagli esatti dell'accettazione. L'SC lavorerà per finalizzare l'accettazione nelle prossime settimane.

Prima della transizione completa alle build non GIL, prevediamo di ottenere il pieno supporto della community per queste build, oltre a fornire ulteriori API C e API Python per abilitare il multithreading sicuro nel codice esistente.

Infine, come già accennato, si prevede che il passaggio al terzo stadio possa avvenire tra almeno 5 anni e la data probabile per PEP-0703 è il rilascio di Python 3.13, previsto per il prossimo autunno.

Se si interessati a saperne di più, puoi controllare i dettagli nel seguente link