Espero que alguém possa fornecer algumas dicas sobre o que é fundamentalmente diferente sobre a Java Virtual Machine que permite implementar threads de maneira adequada, sem a necessidade de um Global Interpreter Lock (GIL), enquanto o Python exige esse mal.
O Python (a linguagem) não precisa de um GIL (e é por isso que ele pode ser implementado perfeitamente na JVM [Jython] e .NET [IronPython], e essas implementações multithread livremente). O CPython (a implementação popular) sempre usou um GIL para facilitar a codificação (especialmente a codificação dos mecanismos de coleta de lixo) e a integração de bibliotecas C-codificadas não seguras para thread (costumava haver muitas delas por aí; -)
O projeto Unladen Swallow , entre outros objetivos ambiciosos, planeja uma máquina virtual sem GIL para Python - para citar esse site: "Além disso, pretendemos remover o GIL e corrigir o estado de multithreading em Python. Acreditamos que isso seja possível através da implementação de um sistema de GC mais sofisticado, algo como o IBM's Recycler (Bacon et al, 2001). "
A JVM (pelo menos hotspot) tem um conceito semelhante ao "GIL", é muito mais fina em sua granularidade de bloqueios, a maior parte disso vem dos GCs em hotspot, que são mais avançados.
No CPython, é um grande bloqueio (provavelmente não tão verdadeiro, mas bom o suficiente para o argumento), na JVM é mais difundido com conceitos diferentes, dependendo de onde é usado.
Veja, por exemplo, vm / runtime / safepoint.hpp no código do ponto de acesso, o que é efetivamente uma barreira. Uma vez em um ponto seguro, a VM inteira parou em relação ao código java, assim como a VM python para no GIL.
No mundo Java, esses eventos de pausa da VM são conhecidos como "pare o mundo"; nesses pontos, apenas o código nativo que está vinculado a determinados critérios é de execução livre; o restante da VM foi interrompido.
Além disso, a falta de um bloqueio grosseiro no java torna a JNI muito mais difícil de escrever, pois a JVM oferece menos garantias sobre seu ambiente para chamadas de FFI, uma das coisas que o cpython facilita bastante (embora não seja tão fácil quanto usar ctypes).
fonte
Há um comentário abaixo nesta postagem do blog http://www.grouplens.org/node/244 que sugere o motivo pelo qual foi tão fácil dispensar um GIL para IronPython ou Jython; é que o CPython usa contagem de referência, enquanto as outras 2 VMs têm coletores de lixo.
A mecânica exata do porquê disso é que eu não entendo, mas parece uma razão plausível.
fonte
Neste link, eles têm a seguinte explicação:
... "Partes do intérprete não são seguras para threads, embora principalmente porque torná-las todas seguras para threads pelo uso massivo de bloqueios reduzisse extremamente o encadeamento único ( fonte ). Isso parece estar relacionado ao coletor de lixo CPython usando a contagem de referência (a JVM e o CLR não e, portanto, não precisa bloquear / liberar uma contagem de referência todas as vezes.) Mas mesmo que alguém pensasse em uma solução aceitável e a implementasse, as bibliotecas de terceiros ainda teriam os mesmos problemas ".
fonte
O Python não possui jit / aot e o período em que foi gravado em processadores multithread não existia. Como alternativa, você pode recompilar tudo no Julia lang que não possui GIL e obter algum aumento de velocidade no seu código Python. O Jython também é uma droga, é mais lento que o Cpython e Java. Se você quiser se ater ao Python, considere usar plug-ins paralelos, não obterá um aumento instantâneo de velocidade, mas poderá fazer programação paralela com o plug-in correto.
fonte