Spero che qualcuno possa fornire alcune informazioni su ciò che è fondamentalmente diverso nella Java Virtual Machine che gli consente di implementare correttamente i thread senza la necessità di un Global Interpreter Lock (GIL), mentre Python richiede un tale male.
Risposte:
Python (il linguaggio) non ha bisogno di un GIL (motivo per cui può essere perfettamente implementato su JVM [Jython] e .NET [IronPython], e quelle implementazioni multithread liberamente). CPython (l'implementazione popolare) ha sempre usato un GIL per facilitare la codifica (in particolare la codifica dei meccanismi di garbage collection) e l'integrazione di librerie con codice C non thread-safe (c'erano un sacco di quelli in giro; -).
Il progetto Unladen Swallow , tra gli altri obiettivi ambiziosi, pianifica una macchina virtuale senza GIL per Python - per citare quel sito, "Inoltre, intendiamo rimuovere il GIL e correggere lo stato del multithreading in Python. Crediamo che sia possibile attraverso l'implementazione di un sistema GC più sofisticato, qualcosa come IBM Recycler (Bacon et al, 2001). "
Il JVM (almeno hotspot) ha un concetto simile al "GIL", è solo molto più fine nella sua granularità di blocco, la maggior parte di questo deriva dai GC nell'hotspot che sono più avanzati.
In CPython è un grande blocco (probabilmente non è così vero, ma abbastanza buono per amor di argomenti), nella JVM è più diffuso con concetti diversi a seconda di dove viene utilizzato.
Dai un'occhiata, ad esempio, a vm / runtime / safepoint.hpp nel codice hotspot, che è effettivamente una barriera. Una volta in un punto di sicurezza, l'intera VM si è arrestata per quanto riguarda il codice java, proprio come la VM di Python si ferma al GIL.
Nel mondo Java tali eventi di pausa della VM sono noti come "stop-the-world", in questi punti solo il codice nativo associato a determinati criteri è in esecuzione libera, il resto della VM è stato arrestato.
Inoltre la mancanza di un blocco grossolano in Java rende JNI molto più difficile da scrivere, poiché la JVM offre meno garanzie sul suo ambiente per le chiamate FFI, una delle cose che cpython rende abbastanza facile (anche se non facile come l'uso di ctypes).
C'è un commento in basso in questo post del blog http://www.grouplens.org/node/244 che suggerisce il motivo per cui è stato così facile rinunciare a un GIL per IronPython o Jython, è che CPython utilizza il conteggio dei riferimenti mentre le altre 2 macchine virtuali hanno i garbage collector.
La meccanica esatta del perché questo è così non capisco, ma sembra una ragione plausibile.
In questo link hanno la seguente spiegazione:
... "Parti dell'interprete non sono thread-safe, anche se principalmente perché renderle tutte thread-safe con un uso massiccio del blocco rallenterebbe estremamente il single-thread ( sorgente ). Questo sembra essere correlato al garbage collector di CPython usando il conteggio dei riferimenti (JVM e CLR no, e quindi non è necessario bloccare / rilasciare ogni volta un conteggio dei riferimenti). Ma anche se qualcuno pensasse a una soluzione accettabile e la implementasse, le librerie di terze parti avrebbero comunque gli stessi problemi. "
Python manca di jit / aot e il periodo di tempo in cui è stato scritto su processori multithread non esisteva. In alternativa, puoi ricompilare tutto in Julia lang che manca di GIL e ottenere un aumento di velocità sul tuo codice Python. Anche Jython fa schifo è più lento di Cpython e Java. Se si desidera attenersi a Python, considerare l'utilizzo di plugin paralleli, non si otterrà un aumento di velocità istantaneo ma è possibile eseguire la programmazione parallela con il plugin giusto.