Espero que alguien pueda darnos una idea de lo que es fundamentalmente diferente acerca de la Máquina Virtual Java que le permite implementar hilos muy bien sin la necesidad de un bloqueo de intérprete global (GIL), mientras que Python necesita un mal tan grande.¿Por qué no hay GIL en la máquina virtual Java? ¿Por qué Python necesita uno tan malo?
Python (el idioma) no necesita un GIL (razón por la cual puede implementarse perfectamente en JVM [Jython] y .NET [IronPython], y esas implementaciones se reproducen de forma múltiple). CPython (la popular implementación) siempre ha usado un GIL para facilitar la codificación (especialmente la codificación de los mecanismos de recolección de basura) y la integración de librerías con codificación C no filiformes (solía haber un montón de ésas alrededor; -).
El proyecto Unladen Swallow, entre otros objetivos ambiciosos, hace plan una máquina virtual GIL-libre para Python - para citar a ese sitio, "Además, tenemos la intención de quitar el GIL y fijar el estado de múltiples hilos en Python Nos. creen que esto es posible mediante la implementación de un sistema GC más sofisticado, algo así como Recycler de IBM (Bacon et al, 2001) ".
La JVM (al menos punto de acceso) tiene un concepto similar al "GIL", es mucho más fino en su granularidad de bloqueo, la mayoría de esto proviene de los puntos de acceso del GC que están más avanzados.
En CPython es un gran bloqueo (probablemente no tan cierto, pero lo suficientemente bueno como argumento), en la JVM está más extendido con diferentes conceptos según el lugar donde se usa.
Observe, por ejemplo, vm/runtime/safepoint.hpp en el código del punto de acceso, que es efectivamente una barrera. Una vez en un punto seguro, toda la máquina virtual se detuvo con respecto al código de Java, al igual que la máquina virtual de python se detiene en el GIL.
En el mundo de Java, estos eventos de pausa de VM se conocen como "detener al mundo", en estos puntos solo el código nativo que está sujeto a ciertos criterios se ejecuta libremente, el resto de la VM se ha detenido.
También la falta de un bloqueo aproximado en Java hace que JNI sea mucho más difícil de escribir, ya que la JVM ofrece menos garantías sobre su entorno para las llamadas FFI, una de las cosas que cpython hace bastante fácil (aunque no tan fácil como ctypes).
+1 para mencionar los puntos de seguridad – selig
Hay un comentario abajo en esta publicación de blog http://www.grouplens.org/node/244 que insinúa la razón por la cual era tan fácil prescindir de un GIL para IronPython o Jython, es que CPython usa recuento de referencias mientras que las otras 2 VM tienen recolectores de basura.
La mecánica exacta de por qué esto es así no lo entiendo, pero suena como una razón plausible.
Cuando comparte promiscuamente objetos entre hilos, trabajar más cuando nadie tiene una referencia a un objeto particular es moderadamente incómodo. El recuento de referencias con un bloqueo global es una forma (costosa). Una forma diferente de resolverlo hubiera sido dejar solo un hilo a la vez con referencias al objeto, lo que haría que la mayor parte de la actividad fuera local del subproceso a un costo que haría que las comunicaciones entre subprocesos fueran más incómodas. Personalmente, creo que es revelador que HPC utiliza el paso de mensajes entre procesadores y memoria no compartida, y que lo hace por razones de escalabilidad ... –
Python carece de jit/aot y el marco de tiempo en el que se escribió en los procesadores multiproceso no existía. Alternativamente, podrías recompilar todo en Julia Lang, que carece de GIL y obtener un impulso de velocidad en tu código de Python. También Jython chupa es más lento que Cpython y Java. Si quiere apegarse a Python, considere usar complementos paralelos, no obtendrá un aumento de velocidad instantáneo, pero puede hacer una programación paralela con el complemento correcto.
En este link tienen la siguiente explicación:
... "Partes de la intérprete no están protegidas por hebras, aunque sobre todo porque, al hacer a todos ellos multi-hilo por el uso masivo de bloqueo frenaría extremadamente único subproceso (source) Esto parece estar relacionado con el recolector de basura CPython que utiliza el recuento de referencias (la JVM y la CLR no lo hacen, y por lo tanto no es necesario bloquear/liberar un recuento de referencia cada vez).Pero incluso si alguien pensara en una solución aceptable y la implementara, las bibliotecas de terceros seguirían teniendo los mismos problemas. "
Eso tiene sentido ... gracias Alex – AgentLiquid
Alex, ¿qué hay de los viejos intentos de eliminar el GIL, wasn Hay un montón de sobrecarga con eso (un factor de 2 es lo que recuerdo)? –
Sí Bartosz, Greg Stein lo midió en 1999. La recolección de basura por recuento de referencias fue el asesino, lo que obligó a una gran sobrecarga de bloqueo de grano fino. ¿Por qué un GC más avanzado es crucial allí. –