기술적으로 Erlang의 프로세스가 OS 스레드보다 효율적인 이유는 무엇입니까?
얼랭의 특성
에서 얼랑 프로그래밍 (2009 년) :
Erlang 동시성은 빠르고 확장 가능합니다. Erlang 가상 머신은 생성 된 모든 프로세스에 대해 OS 스레드를 생성하지 않기 때문에 프로세스가 간단합니다. 기본 운영 체제와 상관없이 VM에서 생성, 예약 및 처리됩니다. 결과적으로 프로세스 작성 시간은 마이크로 초 단위이며 동시에 존재하는 프로세스 수와 무관합니다. 이를 Java 및 C #과 비교하십시오. 모든 프로세스에 대해 기본 OS 스레드가 작성됩니다. Erlang을 사용하면 두 언어보다 성능이 훨씬 뛰어납니다.
에서 동시성 얼랑 (PDF)에서 지향 프로그래밍 (슬라이드) (2003)
Erlang 프로세스를 만드는 데 걸리는 시간은 1µs에서 2,500 프로세스까지 일정합니다. 이후 최대 30,000 개의 프로세스에서 약 3µs까지 증가합니다. Java 및 C #의 성능이 그림의 맨 위에 표시됩니다. 프로세스 수가 적 으면 프로세스를 만드는 데 약 300µs가 걸립니다. 2 천 개 이상의 프로세스를 만드는 것은 불가능합니다.
최대 30,000 개의 프로세스에서 두 Erlang 프로세스간에 메시지를 보내는 시간은 약 0.8µs입니다. C #의 경우 최대 프로세스 수 (약 1800 개 프로세스)까지 메시지 당 약 50µs가 걸립니다. Java는 훨씬 더 나빴습니다. 최대 100 개의 프로세스에 대해 메시지 당 약 50µs가 소요 된 후 약 1000 개의 Java 프로세스가있을 때 메시지 당 10ms로 빠르게 증가했습니다.
내 생각
Erlang 프로세스가 새로운 프로세스를 생성하는 데 훨씬 더 효율적이고 프로세스 당 메모리 풋 프린트가 훨씬 작은 이유를 기술적으로 완전히 이해하지 못합니다. OS와 Erlang VM 모두 예약, 컨텍스트 전환을 수행하고 레지스터 등의 값을 추적해야합니다.
왜 Erlang의 프로세스와 동일한 방식으로 OS 스레드가 구현되지 않습니까? 그들은 더 많은 것을 지원해야합니까? 그리고 왜 더 큰 메모리 공간이 필요합니까? 왜 산란과 의사 소통이 느려 집니까?
기술적으로 Erlang의 프로세스가 생성 및 통신에있어 OS 스레드보다 효율적인 이유는 무엇입니까? 그리고 왜 OS의 스레드가 동일한 효율적인 방식으로 구현되고 관리 될 수 없습니까? 왜 OS 스레드가 더 큰 메모리 풋 프린트와 더 느린 스폰 및 통신을 갖습니까?
더 많은 독서
- SMP에 중점을 둔 Erlang VM 내부 (2008)
- Java와 Erlang의 동시성 (pdf) (2004)
- Java의 스레드 및 Erlang의 프로세스 성능 측정 (1998)
몇 가지 기여 요인이 있습니다.
- Erlang 프로세스는 OS 프로세스가 아닙니다. Erlang VM은 경량의 협업 스레딩 모델을 사용하여 Erlang VM에 의해 구현됩니다 (Erlang 수준에서는 선제 적이지만 협력 적으로 예약 된 런타임 제어하에 있음). 즉, 알려진 제어 된 지점에서만 전환하므로 전체 CPU 상태 (일반, SSE 및 FPU 레지스터, 주소 공간 매핑 등)를 저장할 필요가 없기 때문에 컨텍스트 전환이 훨씬 저렴합니다.
- Erlang 프로세스는 동적으로 할당 된 스택을 사용하며, 매우 작은 규모로 시작하여 필요에 따라 확장됩니다. 이를 통해 사용 가능한 모든 RAM을 빨아 들이지 않고도 수천, 심지어 수백만 개의 Erlang 프로세스를 생성 할 수 있습니다.
- Erlang은 단일 스레드였으며 프로세스 간 스레드 안전성을 보장 할 필요가 없었습니다. 이제 SMP를 지원하지만 동일한 스케줄러 / 코어에서 Erlang 프로세스 간의 상호 작용은 여전히 매우 가볍습니다 (코어마다 별도의 실행 큐가 있음).
좀 더 조사한 후 Joe Armstrong의 프레젠테이션을 찾았습니다.
에서 얼랑 - 동시 세계 (프레젠테이션) 소프트웨어 (13 분에) :
[Erlang]은 동시 언어입니다. 즉, 스레드는 프로그래밍 언어의 일부이며 운영 체제에 속하지 않습니다. 그것은 실제로 Java 및 C ++와 같은 프로그래밍 언어의 문제입니다. 스레드는 프로그래밍 언어가 아니며 스레드는 운영 체제에있는 것으로 운영 체제에있는 모든 문제를 상속합니다. 문제 중 하나는 메모리 관리 시스템의 세분성입니다. 운영 체제의 메모리 관리는 전체 메모리 페이지를 보호하므로 스레드가 될 수있는 가장 작은 크기는 페이지의 가장 작은 크기입니다. 실제로 너무 큽니다.
당신이 당신의 컴퓨터에 더 많은 메모리를 추가하는 경우 - 당신은 페이지 테이블의 세분화가 진행되도록 메모리를 보호하는 비트 수가 같아 - 당신은 몇 백 바이트에서 실행 알고 프로세스에 대한 말의 64KB의를 사용하여 끝낸다.
나는 그것이 전부는 아니지만 적어도 내 질문에 대한 답이라고 생각합니다.
어셈블러에서 코 루틴을 구현하고 성능을 측정했습니다.
Erlang 프로세스로 알려진 코 루틴 간 전환은 최신 프로세서에서 약 16 개의 명령과 20 나노초가 걸립니다. 또한 전환하려는 프로세스 (예 : 대기열에서 메시지를 수신하는 프로세스를 호출 프로세스에서 수신 프로세스로 직접 전달할 수 있음)를 알고 있으므로 스케줄러가 작동하지 않습니다. 그것은 O (1) 연산입니다.
OS 스레드를 전환하려면 커널을 호출하기 때문에 약 500-1000 나노초가 걸립니다. OS 스레드 스케줄러는 O (log (n)) 또는 O (log (log (n))) 시간에 실행될 수 있으며, 수만 또는 수백만 개의 스레드가있는 경우 눈에 띄기 시작합니다.
따라서 스위칭의 기본 작업이 더 빠르며 스케줄러가 덜 자주 실행되므로 Erlang 프로세스가 더 빠르고 확장 성이 뛰어납니다.
Erlang 프로세스 는 다른 언어의 녹색 스레드 에 해당합니다 (대략) . 프로세스간에 OS 강제 분리가 없습니다. (언어 강제 분리가있을 수 있지만 Erlang이 다른 것보다 더 나은 작업을 수행하더라도 보호 수준은 떨어집니다.) 너무 가벼워서 훨씬 더 광범위하게 사용할 수 있습니다.
반면에 OS 스레드는 다른 CPU 코어에서 간단하게 예약 할 수 있으며 (대부분) 독립적 인 CPU 바인딩 처리를 지원할 수 있습니다. OS 프로세스는 OS 스레드와 비슷하지만 OS 강제 분리가 훨씬 강력합니다. 이러한 기능의 가격은 OS 스레드 및 프로세스가 더 비싸다는 것입니다.
차이점을 이해하는 또 다른 방법은 이것입니다. JVM 위에 Erlang 구현을 작성한다고 가정하면 (특히 미친 제안은 아님) 각 Erlang 프로세스를 상태가있는 객체로 만듭니다. 그런 다음 Erlang 프로세스를 실행하는 스레드 인스턴스 풀 (일반적으로 호스트 시스템의 코어 수에 따라 크기가 조정 됨)이 실제 Erlang 런타임 BTW에서 조정 가능한 매개 변수입니다. 그러면 사용 가능한 실제 시스템 리소스에 수행 할 작업이 분산됩니다. 작업을 수행하는 매우 깔끔한 방법이지만 완전히 의존합니다.각각의 개별 Erlang 프로세스가 그다지 많은 것을하지 않는다는 사실에. 물론 괜찮습니다. Erlang은 개별 프로세스가 프로그램을 실행하는 프로세스의 전체 앙상블이므로 무거운 프로세스를 요구하지 않도록 구성되었습니다.
여러면에서 실제 문제는 용어 중 하나입니다. Erlang이 프로세스를 호출하는 것 (그리고 CSP, CCS, 특히 π- 미적분에서 동일한 개념에 강력하게 대응하는 것)은 C 헤리티지 언어 (C ++, Java, C # 및 다른 많은 것들) 프로세스 또는 스레드를 호출하십시오. 있습니다 어떤 유사성 (모든 동시 실행의 몇 가지 개념을 포함한다)하지만 동등한 확실히 없다. 누군가가“공정”이라고 말할 때주의하십시오. 그들은 완전히 다른 것을 의미하는 것으로 이해할 수도 있습니다…
I think Jonas wanted some numbers on comparing OS threads to Erlang processes. The author of Programming Erlang, Joe Armstrong, a while back tested the scalability of the spawning of Erlang processes to OS threads. He wrote a simple web server in Erlang and tested it against multi-threaded Apache (since Apache uses OS threads). There's an old website with the data dating back to 1998. I've managed only to find that site exactly once. So I can't supply a link. But the information is out there. The main point of the study showed that Apache maxed out just under 8K processes, while his hand written Erlang server handled 10K+ processes.
Because Erlang interpreter has only to worry about itself, the OS has many other things to worry about.
one of the reason is erlang process is created not in the OS, but in the evm(erlang virtual machine), so the cost is smaller.
'Programming' 카테고리의 다른 글
| Java NIO FileChannel 및 FileOutputstream 성능 / 유용성 (0) | 2020.05.29 |
|---|---|
| 다른 곳에서 앱 실행 (iPhone) (0) | 2020.05.29 |
| 안드로이드 웹뷰 느림 (0) | 2020.05.29 |
| HttpClient-작업이 취소 되었습니까? (0) | 2020.05.29 |
| Websockets 클라이언트 API의 HTTP 헤더 (0) | 2020.05.29 |