파이썬 GIL : multithreading, multiprocessing

 

안녕하세요. 이 비디오에서는 Python에서 멀티프로세싱과 멀티스레딩을 비교해보겠습니다. 이제 Python의 멀티스레딩과 관련하여 두 가지 주장을 많이 듣습니다. 첫 번째는 Python이 멀티스레드를 지원한다는 것이고, 두 번째는 Python이 멀티스레드를 지원하지 않는다는 것입니다. 그렇다면 어느 것이 맞을까요? 제가 생각하기에는 정확한 표현은 Python이 멀티스레드를 지원하지만 동시에 여러 스레드가 실행될 수 없다는 것입니다. 즉, 두 개의 스레드가 동시에 실행될 수는 없습니다.

그렇다면 스레드란 무엇일까요? 이를 이해하기 위해 먼저 프로세스가 무엇인지 알아야 합니다. 프로세스는 프로그램의 인스턴스입니다. 예를 들어, Firefox의 인스턴스나 여러 개의 Microsoft Word 인스턴스가 있을 수 있습니다. 프로세스는 코드와 데이터를 위해 메모리가 할당됩니다. 프로세스는 최소 하나의 스레드를 가지며, 이 스레드는 자체 레지스터와 스택을 가집니다. 이 스레드는 프로세스의 데이터에 접근할 수 있습니다. 스레드는 운영체제가 관리할 수 있는 가장 작은 명령어 시퀀스입니다. 즉, 운영체제는 스레드가 언제 얼마나 오래 실행될 수 있는지를 결정합니다. 프로세스는 다른 스레드를 생성하거나 멀티스레드를 가질 수 있으며, 각 스레드는 자체 레지스터와 스택, 즉 메모리에서의 고유 공간을 가집니다. 그러나 가장 중요한 것은 스레드가 프로세스의 메모리 공간에 접근할 수 있다는 점입니다. 따라서 스레드는 프로세스 내에 보관된 데이터에 접근할 수 있습니다.

심지어 Python 구현체가 커널 스레드 대신 사용자 수준의 스레드를 생성하더라도, 스레드 패키지를 사용하는 사용자는 프로세스의 데이터에 접근할 수 있습니다. 동일한 프로그램의 또 다른 인스턴스를 실행하면 고유한 코드와 데이터 공간을 메모리에 가집니다. 이러한 프로세스는 모두 고유의 스레드를 가질 수 있습니다. 그러나 가장 중요한 점은 프로세스 간에는 데이터가 접근 불가능하다는 것입니다. 한 프로세스의 데이터 공간은 다른 프로세스에서 접근할 수 없습니다. 두 프로세스가 데이터를 공유하려면 큐나 파이프를 통해야 합니다. 마찬가지로 스레드도 큐와 파이프를 사용해 데이터를 공유할 수 있지만, 파이프와 큐에는 고려해야 할 오버헤드가 있습니다.

이제 Python에서의 스레드와 프로세스를 좀 더 자세히 살펴봅시다. 예를 들어, 프로세스 0과 프로세스 1이라는 두 개의 프로세스가 있습니다. 각 프로세스는 스레드 0과 스레드 1이라는 두 개의 스레드를 가집니다. 4코어 CPU에서 어떤 일이 일어나는지 고려해보면, Python의 스레드는 동시적으로 실행되지만 병렬로 실행되지는 않습니다. 즉, 각 스레드는 시간적으로 분할되어 약간씩 진행되지만, 동일한 프로세스의 두 스레드는 절대 동시에 실행되지 않습니다. 스레드와 프로세스는 물리적 CPU 코어에서 이리저리 이동할 수 있습니다. 이 동작은 운영체제에서 특정 CPU 코어에 대한 친화성을 요청하여 억제할 수 있지만, 이는 운영체제가 결정할 문제입니다. 어쨌든, 주어진 프로세스의 각 스레드는 동시에 실행될 수 없습니다. 여기서 가장 중요한 것은 Python에서 동일한 프로세스의 두 스레드가 동시에 작동할 수 없다는 점입니다. 반면에 프로세스는 동시에 실행될 수 있습니다. 즉, 개별 프로세스의 스레드 0과 스레드 1은 각각 개별 프로세스에 속하기 때문에 동시에 실행될 수 있습니다.

스레드가 실행되기 위해서는 프로세스 내에서 보호된 전역 인터프리터 잠금을 획득해야 합니다. 이는 한 번에 하나의 스레드만 실행할 수 있도록 보장하여 스레드 안전성을 유지합니다. 여기서 스레드 안전성이란 데드락이 발생할 수 없음을 의미합니다. 이는 단일 스레드 성능을 향상시키지만, 프로세스 내에서 동시 멀티스레딩을 방지합니다. 다시 말해, 두 개의 스레드가 동시에 실행될 수 없다는 것입니다. 이는 CPU를 많이 사용하는 작업이 병렬로 수행될 수 없다는 의미입니다. 하지만 좋은 점은 IO 제한 스레드는 거의 영향을 받지 않습니다. 대부분의 시간을 데이터가 들어오기를 기다리거나 데이터가 나가기 위한 신호를 기다리는 데 소비하기 때문입니다.

이제 CPU 바운드 작업 대신 IO 바운드 작업을 고려해 봅시다. 여기서 각 프로세스의 스레드 0이 IO 바운드 작업을 수행한다고 가정합니다. 스레드 0은 IO 작업을 가지며, 이러한 IO 작업은 차단됩니다. 즉, IO 요청이 발생하면 스레드는 반환 값을 기다려야 합니다. 예를 들어 파일을 읽거나 쓰거나, 시리얼 포트에서 데이터를 읽거나 쓰거나, URL을 가져오는 경우가 있습니다. Python에서는 IO 요청이 발생하면 인터프리터가 전역 인터프리터 잠금을 해제하여 다른 스레드가 실행될 시간을 허용합니다. 스레드 1이 많은 작업을 수행하는 CPU 제한 작업이라면, 가끔 IO 작업을 수행하기 위해 중단되는 것은 허용됩니다. 특히 대안이 긴 처리 작업을 수행한 다음 데이터를 요청하고 기다려야 하는 경우라면 더욱 그렇습니다. Python 스레딩을 사용하면 다음 작업이 요청되는 동안 작업을 수행할 수 있습니다.

이제 Python에서 스레드와 프로세스를 몇 가지 다른 측정 지표를 사용하여 비교해 봅시다. 설정 비용 측면에서 스레드는 시간과 자원 면에서 프로세스보다 비용이 적게 듭니다. 처리 방식에서는 CPython 인터프리터가 스레드를 처리하고, 운영체제가 프로세스를 처리합니다. 메모리 접근에서는 스레드가 호스트 프로세스의 모든 데이터에 접근할 수 있으며, 이 데이터 공간을 다른 스레드와 공유할 수 있습니다. 반면에 프로세스는 별도의 데이터 공간을 가집니다. 실행 측면에서는 둘 다 동시적이지만, 중요한 점은 Python에서 스레드는 병렬적이지 않다는 것입니다. 두 스레드는 동시에 실행될 수 없고, 프로세스는 가능합니다.

이해하기 어려울 수 있으므로 예를 들어 보겠습니다. 여기에는 타임스탬프 t0와 배열을 입력으로 받는 함수가 있습니다. 배열은 첫 번째 열에 50,000 나노초(즉, 50 마이크로초) 간격으로 시간을 가지며, 두 번째 열에는 0이 설정됩니다. 함수는 타임스탬프 이후의 시간을 성능 카운터를 사용하여 평가하는 무한 루프에 들어갑니다. 성능 카운터가 반환한 시간이 75,000 나노초인 경우, 두 번째 열의 두 번째 행이 증가합니다. 시간이 배열의 최대 시간을 초과하면 함수가 반환됩니다. 결국 배열은 50 마이크로초 시간 간격 내에서 루프가 실행된 횟수로 채워지게 됩니다. 이 함수는 항상 무언가를 수행하는 집중적인 함수이며, 중요한 것은 백그라운드에서 멀티스레드로 작동하지 않는다는 것입니다. 따라서 실제로 단일 코어 제한입니다.

이제 threading 라이브러리를 가져와 여러 스레드를 생성하고, 이 배열의 깊은 복사본을 각 스레드에 제공합니다. 그런 다음 각 스레드를 실행하여 배열의 깊은 복사본이 이 함수 f의 데이터로 채워지도록 합니다. 그렇다면 어떤 모습일까요? 여기 4개의 스레드 결과가 있습니다. 참고로 저는 16개의 커널 스레드가 동시에 실행될 수 있는 8코어 CPU를 사용하고 있습니다. 4개만 사용하고 있습니다. 왼쪽의 가로 막대는 특정 시간 간격에 대해 히스토그램이 채워졌는지를 나타냅니다. 색상이 있는 곳은 스레드가 작업을 수행하고 있음을 의미합니다. 언제든지 한 번에 하나의 스레드만 실행되고 있음을 알 수 있습니다. 스레드는 모두 15밀리초의 개별 청크로 나누어져 있으며, 이는 우연이 아닙니다. CPython은 스레드가 차단 IO 호출에 도달하거나 15밀리초가 경과할 때까지 실행을 허용합니다. 매우 드물게 스레드는 15밀리초 이후에 다시 실행할 수 있으며, 이는 약간의 일시 중지를 초래합니다. 이 3초 동안 생성된 활동 플롯에서 이는 200개의 스레드 할당 청크를 나타냅니다. 각 스레드가 실행된 시간은 오른쪽에 플로팅되어 있습니다. 모든 스레드가 동일한 작업을 수행함에도 불구하고 스레드의 실행 시간이 고르지 않습니다. 전체적으로 3초 동안 모든 스레드에서 약 3초의 작업이 수행되었고, 모든 스레드의 함수 호출 수는 약 200만 번이었습니다.

8개의 스레드를 사용할 때 상황은 매우 유사하지만, 이 3초 동안 스레드가 할당된 시간에 훨씬 더 많은 비대칭이 발생합니다. 일부 청크에서 약간의 중단이 보이며, 이는 운영체제가 개입하여 스레드를 잠시 중단시키고 다른 물리적 또는 가상 프로세서로 이동시키는 등의 작업을 수행하는 경우입니다. 이는 함수 반복이 완료되지 않은 최소 50 마이크로초의 창을 초래합니다. 8개의 스레드를 할당했음에도 불구하고 수행된 실제 함수 호출 수는 약 200만 번으로, 스레드 수를 두 배로 늘렸음에도 불구하고 실제 함수 호출 수는 거의 동일합니다.

16개의 스레드를 사용할 때 첫 번째 3초 테스트에서 매우 큰 비대칭이 나타납니다. 전체적으로 3초 동안 16개의 스레드에서 약 3초의 작업이 수행되며, 모든 스레드에서 큰 비대칭이 발생합니다. 낮은 인덱스를 가진 스레드가 더 많은 초기 시간을 할당받는 경향이 있습니다.

사실, 지금 보시다시피, 스레드 12, 13, 14, 15 중 어느 것도 실제로 실행할 시간이 할당되지 않았습니다. 그래서 16개의 스레드의 총 함수 호출 수는 약 200만 번으로, 8개의 스레드를 사용할 때와 비교해도 개선된 점이 없습니다. 그렇다면, 이러한 CPU 제한 작업을 수행할 때 어떻게 성능을 향상시킬 수 있을까요? 멀티코어 시스템을 활용하여 성능을 실제로 높이려면 멀티프로세싱을 사용하는 것이 좋습니다. 멀티프로세싱은 사람들이 실제로 멀티스레딩이라고 생각하는 작업을 수행할 수 있는 표준 파이썬 라이브러리입니다. 멀티프로세싱을 통해 여러 프로세스를 동시에 처리할 수 있습니다.

코드를 수정하여 이를 활용할 수 있습니다. 첫 번째로, 특히 윈도우에서 사용할 때 offset 시간을 time.time으로 변경해야 합니다. 성능 카운터는 프로세스 시작 시간에 상대적이기 때문에 여러 프로세스를 다른 시간에 생성하면 offset으로 perf counter를 사용할 수 없습니다. time.clock도 사용 불가능하며, 파이썬 3.8에서 제거될 예정입니다. time.process_time도 프로세스에 특정하기 때문에 사용할 수 없습니다. 다행히도, 최소한 제 컴퓨터에서는 time.time 함수가 약 1밀리초의 해상도를 가지며 프로세스에 특정되지 않습니다. 1밀리초는 허용 가능한 offset이므로, 우리는 동기화를 위해 time.time을 사용하고 높은 성능의 binning을 위해 time.perf_counter를 사용합니다. 또한, 프로세스는 메모리를 공유하지 않으므로 이번에는 배열을 반환해야 합니다. 우리는 별도의 배열 복사본을 프로세스에 보내야 하며, 프로세스는 이를 다시 보내야 합니다. 따라서 우리는 이 배열의 깊은 복사본을 여러 개 생성하고, multiprocessing.Pool 클래스를 사용하여 워커 풀을 생성합니다. 이 풀은 자동으로 배열을 starmap 함수를 사용하여 전송하고, 반환된 배열도 순서대로 처리합니다. 개별 프로세스에 신뢰할 수 있는 타임스탬프(t0)를 보내 동기화를 보장합니다. 프로세스 간에는 통신을 포함한 많은 오버헤드가 있습니다. 제 채널에 이와 관련된 다른 비디오도 있으니 참고하세요. 이번 비디오에서는 프로세스의 실행 성능만을 살펴보겠습니다.

이제 4개의 프로세스를 사용하여 활동 플롯을 다시 살펴보면, 매우 다른 것을 볼 수 있습니다. 각 프로세스가 동시에 실행되는 것을 명확히 볼 수 있습니다. 또한, 병렬로 실행되기 때문에 처리 시간이 거의 동일합니다. 모든 프로세스는 거의 동시에 시작되며, 작은 배열을 각 프로세스에 보내고 많은 작업을 수행하기 때문에 멀티스레딩보다 약 4배 더 많은 작업을 수행합니다. 실제로, 이 3초 동안 우리는 900만 번의 함수 반복을 수행하여, 멀티스레딩에서 제공된 약 200만 번보다 4배 이상 많은 작업을 수행했습니다. 운영체제가 프로세스를 다른 코어로 전환하는 등의 작업을 할 때 가끔 끊김이 발생할 수 있습니다. 전반적으로 단일 스레드 응용 프로그램에 비해 엄청난 향상이 있습니다.

8개의 프로세스를 사용할 때는 매우 흥미로운 현상을 볼 수 있습니다. 각 프로세스의 시작 시간이 서로 다르며 타임스탬프 정확도를 초과합니다. 이는 여전히 단일 프로세스(메인 프로세스)와 몇 개의 스레드가 데이터를 각 워커 프로세스로 패킹하고 전송하는 작업을 처리하기 때문입니다. 이러한 스레드는 병렬로 실행될 수 없다는 것을 알고 있습니다. 멀티프로세싱은 많은 작업을 수행해야 하는 CPU 제한 작업에 더 적합합니다. 제 CPU는 8개의 코어와 동시에 멀티스레딩을 지원하여 거의 모든 코어를 사용할 수 있으며, 윈도우도 백그라운드 작업을 수행할 충분한 처리 코어를 가지고 있습니다. 가끔 백그라운드 프로세스가 많은 멀티코어 CPU 전원을 요구하여 파이썬 프로세스와 CPU 시간을 경쟁하는 경우도 있습니다. 일반적으로 멀티스레딩보다 8배 더 많은 작업을 수행하고, 총 1,670만 번의 함수 반복이 이루어졌습니다. 이는 4개의 프로세스보다 약 85% 더 많은 작업이며, 8개의 스레드를 사용할 때보다 8배 더 많은 작업을 수행한 것입니다.

다음으로 16개의 프로세스를 사용한 예를 보면 매우 흥미롭습니다. 제 CPU는 8개의 물리적 코어와 동시에 멀티스레딩을 활성화하여 16개의 동시 컴퓨팅 유닛을 가지고 있습니다. 프로세스의 시작 시간이 모두 분산되어 있습니다. 이 분산은 약 180밀리초로, 이전 8개의 스레드의 10밀리초보다 훨씬 큽니다. 이 3초 동안 일부 프로세스는 비교적 중단 없이 실행되지만, 프로세스 9, 10, 13, 14는 계속 중단되어 전체 진행이 낮아집니다. 이는 운영체제가 이러한 프로세스를 관리해야 하며, 가끔 더 중요한 작업이 발생하여 운영체제가 일부 스레드를 중단시키고 다른 작업을 처리해야 하기 때문입니다. 일반적으로 멀티스레딩보다 14배 더 많은 작업을 수행하고 있으며, 총 2,060만 번의 함수 호출이 이루어졌습니다. 이는 8개의 프로세스보다 23% 더 많은 작업이지만, 프로세스 수를 두 배로 늘렸음에도 불구하고 실제 성능 증가가 거의 없는 것은 흥미롭습니다. 이는 실제로 SMT 기술 때문일 수 있습니다. 8개의 물리적 코어와 16개의 동시 코어가 있지만, 실제 성능 증가는 약 25%입니다.

멀티프로세싱과 멀티스레딩의 활동 플롯을 비교하면, 멀티프로세싱이 동일한 시간 동안 더 많은 작업을 수행하고 있음을 알 수 있습니다. 멀티스레딩과 멀티프로세싱에서 실제 작업을 비교해 보면, 멀티스레딩은 스레드를 추가해도 작업량이 증가하지 않았지만, 멀티프로세싱은 8개의 프로세스까지 뛰어난 확장성을 보였습니다. 이는 물리적 CPU 코어 수와 일치하며, 동시 멀티스레딩 기술을 활용하여 추가로 25% 더 많은 작업을 수행했습니다. 운영체제가 여전히 일부 CPU 시간을 필요로 한다는 점을 고려하면, 이러한 결과는 매우 인상적입니다.

우리가 배운 점은 무엇일까요? CPU 제한 작업의 경우, 멀티프로세싱이 가장 적합합니다. 반면, IO 제한 작업(시리얼 데이터 대기, URL 해석 대기 등)에는 멀티스레딩이 적합합니다. 멀티스레딩은 GUI 또는 대화형 기능에 탁월하며, 매우 작은 CPU 시간을 필요로 합니다. 멀티프로세싱이나 멀티스레딩을 잘못 사용하면 프로그램이 더 느려질 수 있으니 주의해야 합니다. numpy와 scipy와 같은 모듈의 백엔드는 최적화되어 있어 멀티프로세싱에서 이득을 얻지 못할 수 있습니다. 따라서 각 경우에 가장 적합한 접근 방식을 선택하는 것이 중요합니다.