Spero che qualcuno possa fornire alcune informazioni su ciò che è fondamentalmente diverso sulla Java Virtual Machine che gli consente di implementare thread piacevolmente senza la necessità di un Global Interpreter Lock (GIL), mentre Python richiede un tale male.Perché non c'è GIL nella Java Virtual Machine? Perché Python ne ha bisogno così tanto?
Python (il linguaggio) non ha bisogno di un GIL (motivo per cui può essere perfettamente implementato su JVM [Jython] e .NET [IronPython] e tali implementazioni multithread liberamente). CPython (la popolare implementazione) ha sempre usato un GIL per facilitare la codifica (specialmente la codifica dei meccanismi di garbage collection) e l'integrazione di librerie con codice C prive di thread (c'era una tonnellata di quelle intorno; -).
Il progetto Unladen Swallow, tra gli altri obiettivi ambiziosi, fa plan una macchina virtuale GIL-libera per Python - per citare quel sito, "Inoltre, abbiamo intenzione di rimuovere il GIL e fissare lo stato di multithreading in Python Noi. crediamo che ciò sia possibile attraverso l'implementazione di un sistema GC più sofisticato, qualcosa come IBM Recycler (Bacon et al, 2001). "
La JVM (almeno hotspot) ha un concetto simile a "GIL", è molto più fine nella sua granularità di blocco, la maggior parte proviene dal GC in hotspot che sono più avanzati.
In CPython è un blocco grande (probabilmente non è vero, ma abbastanza buono per ragioni argomentative), 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 è fermata per quanto riguarda il codice java, proprio come il Python VM si ferma su GIL.
Nel mondo Java tali eventi di interruzione 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.
Anche la mancanza di un blocco grossolano in java rende JNI molto più difficile da scrivere, poiché la JVM rende meno garanzie sul suo ambiente per le chiamate FFI, una delle cose che cpython rende abbastanza facile (anche se non è così facile come usare ctypes).
+1 per la menzione dei punti di sicurezza – selig
C'è un commento in basso in questo post del blog http://www.grouplens.org/node/244 che suggerisce il motivo per cui è stato facile rinunciare a GIL per IronPython o Jython, è che CPython usa il conteggio dei riferimenti mentre le altre 2 VM hanno i garbage collector.
La meccanica esatta del perché è così non riesco, ma sembra un motivo plausibile.
Quando si condivide in modo promiscuo oggetti tra i thread, lavorando fuori quando nessuno ha più un riferimento a un particolare oggetto è moderatamente scomodo. Il conteggio dei riferimenti con un blocco globale è uno (costoso) modo. Un modo diverso per risolverlo sarebbe stato lasciare un solo thread alla volta mantenere i riferimenti all'oggetto, il che renderebbe la maggior parte delle attività thread-local al costo di rendere più complicate le comunicazioni tra thread. Personalmente, penso che stia dicendo che HPC usa il passaggio dei messaggi tra i processori e non la memoria condivisa, e che lo fa per ragioni di scalabilità ... –
Python manca jit/aot e il time frame è stato scritto in processori multithreaded non esisteva. In alternativa puoi ricompilare tutto in Julia lang che manca GIL e guadagnare un po 'di velocità sul tuo codice Python. Anche il tipo Jython di succhia è più lento di Cpython e Java. Se si desidera attenersi a Python, si consideri l'utilizzo di plug-in paralleli, non si otterrà un aumento della velocità istantaneo, ma si può fare la programmazione parallela con il plug-in giusto.
In questo link hanno la seguente spiegazione:
... "Parti l'interprete non sono threadsafe, ma soprattutto perché rendendoli tutti threadsafe dall'uso serratura massiccia rallenterebbe a thread singolo estremamente (source) Questo sembra essere correlato al garbage collector CPython utilizzando il conteggio dei riferimenti (JVM e CLR no, e quindi non è necessario bloccare/rilasciare un conteggio di riferimento ogni volta).Ma anche se qualcuno pensasse a una soluzione accettabile e la implementasse, le librerie di terze parti avrebbero ancora gli stessi problemi. "
Questo ha senso ... grazie Alex. – AgentLiquid
Alex, che dire dei vecchi tentativi di rimuovere il GIL, wasn C'è un sacco di overhead con quello (un fattore 2 è quello che ricordo)? –
Sì Bartosz, Greg Stein lo ha misurato nel 1999. La raccolta dei rifiuti per conteggio di riferimento è stato il killer, costringendo un enorme sovraccarico di chiusura a grana fine. –