나는 누군가가 GIL (Global Interpreter Lock)이 필요없는 스레드를 훌륭하게 구현할 수있게 해주는 Java Virtual Machine과 근본적으로 다른 점에 대한 통찰력을 제공하기를 희망하지만 Python은 그러한 악을 필요로합니다.
답변
파이썬 (언어)에는 GIL이 필요하지 않습니다 (따라서 JVM [Jython] 및 .NET [IronPython]에서 완벽하게 구현 될 수 있으며 이러한 구현은 다중 스레드를 자유롭게 수행 할 수 있습니다). CPython (일반적인 구현)은 항상 코딩 용이성 (가비지 수집 메커니즘의 코딩)과 스레드로부터 안전하지 않은 C 코딩 라이브러리 (통합 된 톤이 많음)의 통합을 위해 GIL을 사용했습니다. -).
공차 제비 프로젝트는 다른 야심 찬 목표 중 수행 계획 파이썬에 대한 GIL없는 가상 머신을 -. 또한, 우리는 GIL을 제거하고 파이썬에서 멀티 스레딩의 상태를 해결하기 위해 의도 “해당 사이트를 인용 우리는이 믿고 IBM의 Recycler (Bacon et al, 2001)와 같은보다 정교한 GC 시스템의 구현을 통해 가능합니다. “
답변
JVM (적어도 핫스팟)은 “GIL”과 유사한 개념을 가지고 있으며, 잠금 세분성이 훨씬 우수합니다.이 중 대부분은 더 발전된 핫스팟의 GC에서 나옵니다.
CPython에서는 하나의 큰 잠금 장치 (아마도 사실은 아니지만 인수에 충분합니다), JVM에서는 사용되는 위치에 따라 다른 개념으로 더 널리 퍼져 있습니다.
예를 들어 핫스팟 코드에서 vm / runtime / safepoint.hpp를 살펴보십시오. 이는 실제로 장벽입니다. 일단 안전 점에 도달하면 파이썬 VM이 GIL에서 중지하는 것처럼 Java 코드와 관련하여 전체 VM이 중지됩니다.
Java 세계에서는 이러한 VM 일시 중지 이벤트를 “세계에서 중지”라고합니다.이 시점에서 특정 기준에 바인딩 된 기본 코드 만 자유롭게 실행되고 나머지 VM은 중지되었습니다.
또한 JVM에 거친 잠금이 없기 때문에 JVM이 cFIthon을 사용하는 것만 큼 쉽지는 않지만 JVM이 FFI 호출에 대한 환경에 대한 보증을 덜 제공하므로 JNI를 작성하기가 훨씬 어려워집니다.
답변
이 블로그 게시물 http://www.grouplens.org/node/244 아래에 IronPython 또는 Jython의 GIL을 너무 쉽게 분배하는 이유를 암시 하는 주석 이 있습니다. CPython은 참조 계산을 사용하지만 다른 2 개의 VM에는 가비지 수집기가 있습니다.
왜 그런지에 대한 정확한 메커니즘은 얻지 못하지만 그럴듯한 이유처럼 들립니다.
답변
이 링크 에는 다음과 같은 설명이 있습니다.
… “인터프리터의 일부는 스레드에 안전하지 않지만, 대부분의 대규모 잠금 사용으로 스레드로부터 안전하도록하면 단일 스레드를 매우 느리게 ( source ) 느리게 할 수 있기 때문에 참조 카운트 (JVM)를 사용하는 CPython 가비지 콜렉터와 관련이있는 것 같습니다. CLR은 매번 참조 카운트를 잠 그거나 해제 할 필요가 없습니다.) 그러나 누군가가 수용 가능한 솔루션을 생각하고 구현하더라도 써드 파티 라이브러리는 여전히 같은 문제를 겪을 것입니다. “
답변
파이썬에는 jit / aot가 없으며 멀티 스레드 프로세서에서 작성된 시간 프레임이 존재하지 않았습니다. 또는 GIL이 부족한 Julia lang의 모든 것을 다시 컴파일하고 Python 코드에서 속도를 향상시킬 수 있습니다. 또한 자이 썬은 Cpython과 Java보다 느리다. 파이썬을 고수하고 싶다면 병렬 플러그인 사용을 고려하면 즉각적인 속도 향상을 얻지 못하지만 올바른 플러그인으로 병렬 프로그래밍을 수행 할 수 있습니다.
답변
