GIL in Python 3.1

Question

Qualcuno conosce il destino di Global Interpreter Lock in Python 3.1 contro l'integrazione del multithreading C ++

Answer 1

GIL è ancora lì in CPython 3.1; i progetti Unladen Swallow hanno lo scopo (tra molti altri aumenti delle prestazioni) di rimuoverlo, ma è ancora lontano dai suoi obiettivi, e sta lavorando su 2.6 per primo con l'intento di portarlo su 3.x per qualsiasi x sarà aggiornato nel momento in cui la versione 2.y è considerata fatta. Per ora, il multiprocessing (anziché il threading) rimane la scelta preferita per l'utilizzo di più core in CPython (anche IronPython e Jython vanno bene, ma al momento non supportano Python 3, né rendono l'integrazione C ++ altrettanto facile; - ).

Answer 2

Si verificheranno cambiamenti significativi in ??GIL per Python 3.2. Dai un'occhiata al Novità di Python 3.2 , e il thread che lo ha avviato nella mailing list .

Mentre le modifiche non significano la fine del GIL, preannunciano guadagni di prestazioni potenzialmente enormi.

Update0

• Le prestazioni generali ottenute con il nuovo GIL nella versione 3.2 di Antoine Pitrou sono state trascurabili e si sono invece concentrate su migliorare i problemi di contesa che si presentano in alcuni casi angolari.
• ammirevole sforzo di David Beazley è stato fatto per implementare un programmatore per migliorare significativamente le prestazioni quando CPU e IO i thread rilegati sono misti, il che è stato purtroppo abbattuto.
• Il lavoro di Unladen Swallow era proposto per la fusione in Python 3.3, ma questo è stato ritirato a causa della mancanza di risultati in quel progetto. PyPy è ora il progetto preferito ed è attualmente richiesta di finanziamento per aggiungere il supporto Python3k. Ci sono poche possibilità che PyPy diventi il ??default al momento.

Negli ultimi 15 anni sono stati compiuti sforzi per rimuovere il GIL da CPython ma per il prossimo futuro è qui per rimanere.

Answer 3

Il GIL non influirà sul codice che non utilizza oggetti Python. In Numpy, rilasciamo GIL per il codice computazionale (chiamate di algebra lineare, ecc ...) e il codice sottostante può usare liberamente il multithreading (in realtà, quelle sono generalmente librerie di terze parti che non sanno nulla di Python)

Answer 4

Il GIL è una buona cosa.

Fai semplicemente rilasciare alla tua applicazione C ++ GIL mentre sta facendo il suo lavoro multithread. Il codice Python continuerà a essere eseguito negli altri thread, incontaminato. Acquisisci il GIL solo quando devi toccare oggetti Python.

Answer 5

Immagino che ci sarà sempre un GIL. Il motivo è la prestazione. Rendere sicuro tutto il thread di accesso di basso livello - significa mettere un mutex attorno ad ogni operazione di hash ecc. È pesante. Ricorda che una semplice dichiarazione come

self.foo(self.bar, 3, val)

Al momento potrebbero già esserci almeno 3 ricerche hashtable (se val è globale) e forse anche molto di più se la cache del metodo non è attiva (a seconda della profondità dell'ereditarietà della classe)

È costoso - ecco perché Java ha abbandonato l'idea e ha introdotto hashtable che non usano una chiamata di monitoraggio per sbarazzarsi del suo "Java Is Slow" marchio di fabbrica.

Answer 6

A quanto ho capito, il "brainfuck" lo scheduler sostituirà GIL da Python 3.2

Scheduler bainfuck di BFS

Answer 7

Se il GIL si sta mettendo in mezzo, usa semplicemente il modulo multiprocessing . Genera nuovi processi ma utilizza il modello di threading e (la maggior parte dei) api. In altre parole, puoi fare un parallelismo basato sui processi in modo simile a un thread.