Una delle caratteristiche più dibattute di Python è il GIL, ovvero il Global Interpreter Lock. Si tratta di un grande blocco che permette a un solo thread di attraversare l’interprete Python in un dato momento. Questo limite impedisce ai programmi CPython multithread di sfruttare appieno i sistemi multiprocessore. Tuttavia, due giorni fa, il team di Python ha ufficialmente accettato la proposta di eliminare questa funzionalità e ha anche fornito un piano sia a breve che a lungo termine per attuare questo cambiamento.
Quando Python è stato rilasciato pubblicamente nel 1991, non supportava i thread né aveva il blocco dell’interprete globale. Il supporto per i thread è stato aggiunto circa un anno dopo, nel 1992, insieme al GIL. In quel periodo, la maggior parte dei programmatori Python non aveva a disposizione CPU multi-core, quindi si riteneva che l’astrazione dei thread fosse sufficiente. Ma col passare del tempo, i computer hanno iniziato a essere dotati di più processori, rendendo necessario trovare una soluzione per gestire il parallelismo.
Il creatore di Python, Guido van Rossum, ha dichiarato in una recente intervista: “Credevamo di aver gestito abbastanza bene l’astrazione dei thread poiché le CPU multi-core non erano ancora diffuse tra i programmatori Python negli anni ’90. Ma quando i progettisti di chip hanno cominciato a mettere più CPU su un singolo chip, si è reso necessario trovare una soluzione per gestire il parallelismo, ed è così che è diventato famoso il GIL. In quel contesto, il GIL era la soluzione che permetteva di condividere l’interprete Python tra tutti i diversi thread del sistema operativo che potevano essere creati. Quindi, finché l’hardware aveva solo una CPU fisica, tutto funzionava bene.”
Allo stesso modo, anche Linux e FreeBSD avevano implementato sistemi di blocco globale, rispettivamente chiamati “big kernel lock” in Linux e “giant lock” in FreeBSD. Questi blocchi consentivano l’elaborazione di un solo thread alla volta da parte dell’interprete. Nel tempo, tuttavia, sono stati sostituiti da “blocchi a grana fine” e altre tecniche per migliorare le prestazioni complessive.
Il GIL è stato mantenuto in Python per tanto tempo per diversi motivi. Inizialmente, il blocco era facile da implementare e non richiedeva codice complesso. Inoltre, molti programmi Python venivano eseguiti su una singola CPU e i programmi a thread singolo funzionavano bene. Inoltre, la presenza del GIL evitava problemi di deadlock e previene alcuni tipi di bug che potrebbero emergere quando si utilizzano “lock a grana fine”.
Tuttavia, con l’aumento dell’uso di Python per lo sviluppo di modelli di intelligenza artificiale basati su reti neurali, i quali possono beneficiare di diversi tipi di parallelismo, il GIL è diventato un ostacolo. Altri linguaggi consentono l’utilizzo dei thread per eseguire diverse parti di un modello AI su core CPU separati, ma il GIL di Python impedisce questa possibilità. Anche in situazioni in cui è necessario gestire più richieste contemporaneamente, l’utilizzo dei thread con Python può incontrare difficoltà a causa del GIL. Esistono alternative al GIL, ma il processo di adozione di queste soluzioni può essere noioso e presenta limitazioni significative.
Per risolvere questa problematica, il team di Python ha iniziato un lungo e accurato processo per rimuovere il GIL. È stata proposta una versione sperimentale a breve termine in cui il GIL verrà disabilitato a scopo di test. Successivamente, in una fase a medio termine, verrà fornito il supporto per questa versione senza GIL, ma questa non sarà l’impostazione predefinita. Infine, a lungo termine, la versione senza GIL diventerà l’interprete predefinito di Python, garantendo al contempo la compatibilità con le versioni precedenti.
Guidato da Sam Gross, Meta ha annunciato che dedicherà un serio team di ingegneri a questa trasformazione, considerata una vittoria per l’ecosistema AI.
Un effetto interessante di questa modifica è che la dipendenza da Rust per calcoli in parallelo tramite più thread diventerà ridondante. Gli sviluppatori potranno continuare a lavorare con Python senza GIL anziché dover passare a un linguaggio diverso.