MPI는 공유 메모리보다 더 어려운 것으로 간주되는 이유는 무엇입니까?

이전의 모든 대답에 동의하지만 완전히 명확하지 않은 핵심 포인트는 MPI가 어렵고 Erlang으로 간주 될 수있는 이유 중 하나는 모델과 도메인의 일치입니다.

얼랭 (Erlang)은 로컬 메모리, 비동기 메시지 전달 및 모든 스레드가 얻을 수있는 어떤 형태의 글로벌 데이터베이스를 사용하여 공유 된 상태를 개념에 기반하고 있습니다. 전체적으로 많은 데이터를 이동하지 않으며 조정이 필요한 100,000 개의 별도 노드로 폭발하지 않는 응용 프로그램 용으로 설계되었습니다.

MPI는 로컬 메모리 및 메시지 전달을 기반으로하며, 데이터를 이동하는 것이 도메인의 핵심 부분 인 문제를 해결하기위한 것입니다. 고성능 컴퓨팅은 문제에 대한 데이터 집합을 가져 와서 여러 컴퓨팅 리소스로 분할하는 데 매우 중요합니다. 그리고 이것은 메시지 전달 시스템에서 꽤 힘든 작업입니다. 데이터가 균형을 유지하면서 명시 적으로 배포되어야하기 때문입니다. 근본적으로, MPI는 공유 메모리가 확장되지 않는다는 불만을 나타내고 있습니다. 또한 100k 프로세서 이상에 퍼져있는 고성능 컴퓨팅을 목표로하고 있습니다.

Erlang은 가능한 한 최상의 성능을 얻으 려하지 않고, 자연스럽게 평행 한 문제를 자연 쓰레드로 분해하려고합니다. 그것은 MPI에 비해 완전히 다른 유형의 프로그래밍 작업을 염두에두고 설계되었습니다.

그래서 Erlang은 pthread와 다른 지역의 이기종 스레드 솔루션과 비교하여, 실제로는 매우 다른 (그리고 어느 정도 본질적으로 더 어려운) 문제 세트를 목표로합니다.

Erlang의 평행법아직구현하기가 꽤 어렵다. 그 말은 당신이 여전히 문제를 어떻게 나눌 지 알아 내야한다는 것을 의미하지만, C 또는 C ++의 일부 MPI 라이브러리와 비교할 때이 어려움을 덜어주는 사소한 것들이 있습니다.

첫째, Erlang의 메시지 전달은 일급 언어 기능이기 때문에 통사론에 의하면 설탕이 더 쉽게 느껴집니다.

또한 Erlang 라이브러리는 모두 Erlang의 메시지 전달을 중심으로 구축되었습니다. 이 지원 구조는 병렬 처리 토지를 향상시키는 데 도움이됩니다. 살펴보기OTP의 구성 요소gen_server, gen_fsm, gen_event와 같은 형식입니다. 이것들은 프로그램을 병렬화하는 데 도움이되는 구조를 사용하기가 매우 쉽습니다.

필자는 erlang의 메시지 전달을 다른 MPI 구현과 차별화 할 수있는 사용 가능한 표준 라이브러리의 견고성이 중요하다고 생각합니다. 실제로 언어 자체의 특정 기능이 아닙니다.

일반적으로 HPC의 동시성은 많은 양의 데이터 작업을 의미합니다. 이런 종류의 병렬성은데이터 병렬 처리운영체제는 메시지 패러다임 패러다임을 사용하는 경우 자신을 구현해야하는 작업의 일정과 배치와 같은 작업을 처리하기 때문에 실제로 OpenMP와 같은 공유 메모리 방식을 사용하여 구현하기가 쉽습니다.

대조적으로 Erlang은작업 병렬 처리제한된 양의 통신과 내결함성 및 복구에 대한 강력한 요구 사항만으로 여러 코드를 동시에 실행해야하는 전화 시스템에서 발생합니다.

이 모델은 대부분의 사람들이 PThread를 사용하는 것과 유사합니다. HPC 응용 프로그램은 작업자간에 교환해야하는 방대한 양의 데이터에 대해 거의 동일한 작업을 수행하는 반면, 각 요청은 다른 스레드에서 처리 할 수있는 웹 서버와 같은 응용 프로그램에 적합합니다.

MPI로 프로그래밍 할 때와 Erlang으로 프로그래밍 할 때 마음가짐과 관련이 있다고 생각합니다. 예를 들어, MPI는 언어에 내장되어 있지 않지만 Erlang에는 메시지 전달 기능이 내장되어 있습니다. 가능한 또 다른 이유는 단순히 메시지를 보내고받는 것과 메시지를 동시에 실행 단위로 나누는 것 사이의 연결이 끊어지기 때문입니다.

Erlang을 사용하면 데이터가 함수 호출에서 함수 호출로 실제로 압축되는 함수 프로그래밍 프레임에서 사고해야합니다. 수신은 언어의 정상적인 구문과 같이 보이는 활성 동작입니다. 이것은 실제로 수행중인 계산과 메시지를 보내거나받는 행위 사이에 더 밀접한 연결을 제공합니다.

MPI를 사용하면 실제 메시지 전달에 대해 생각할 수밖에 없지만 실제로 작업의 분해는 아닙니다. 이러한 사고 체계에는 코드에 솔루션과 메시징 인프라를 작성하는 사이에 컨텍스트 전환이 다소 필요합니다.

토론은 계속 될 수 있지만 공통적 인 견해는 메시지 전달을위한 구조가 실제로 사용중인 프로그래밍 언어와 패러다임에 포함되어 있다면 일반적으로 솔루션을 표현하는 더 좋은 방법이라고 할 수 있습니다. "또는 라이브러리 또는 확장의 형태로 언어에 추가 기능으로 존재합니다.

IT 및 HPC 세계에서 메시지 전달 vs. 공유 메모리의 인식에 왜 그런 차이가 있는지 누가 알 수 있습니까? Erlang과 MPI가 얼랭 스타일의 메시지 전달을 MPI보다 훨씬 쉽게 만드는 메시지 전달을 구현하는 방법의 근본적인 차이점 때문입니까? 아니면 다른 이유가 있습니까?

이유는 단순히 병렬성과 동시성입니다. Erlang은 동시 프로그래밍을 위해 개발되었습니다. HPC는 모두 병렬 프로그래밍에 관한 것입니다. 이것들은 관련이 있지만 다른 목적이다.

동시 프로그래밍은 상당히 비 결정적 인 제어 흐름으로 인해 매우 복잡하며 대기 시간은 종종 중요한 목표입니다. 얼랭 (Erlang)은 불변의 데이터 구조를 사용하여 동시 프로그래밍을 크게 단순화합니다.

병렬 프로그래밍은 훨씬 간단한 제어 흐름을 가지며 목적은 최대 총 처리량 및 대기 시간이 아니라는 점입니다. Erlang과 불변의 데이터 구조를 크게 부적절하게 만드는 효율적인 캐시 사용이 여기에서 훨씬 중요합니다. 이 상황에서 공유 메모리를 변경하는 것이 다루기 쉽고 실질적으로 더 좋습니다. 실제로 캐시 일관성은 하드웨어 가속 메시지 전달을 제공합니다.

마지막으로 이러한 기술적 인 차이 외에도 정치적인 문제가 있습니다. 얼랭 (Erlang) 사람들은 얼랑 (Erlang)이 멀티 코어와 관련이 없다고 주장하면서 멀티 코어 애호가를 타려하고 있습니다. 특히 그들은 뛰어난 확장 성을 강조하므로 절대적 성능을 고려하는 것이 필수적입니다. 얼랭 (Erlang)은 한 코어의 절대 성능이 좋지 않은 데서부터 코어 수에 관계없이 절대 성능이 떨어지는 것까지 쉽게 확장 할 수 있습니다. 상상할 수 있듯이 HPC 커뮤니티에 큰 인상을주지는 않습니다 (그러나 많은 동시 코드에 적합합니다).

MPI 대 OpenMP / UPC : MPI는 문제를 작은 조각으로 나누고 데이터 이동에 대한 책임을집니다. OpenMP / UPC를 사용하면 "모든 데이터가 있습니다."라는 메시지가 표시되면 포인터를 역 참조하면됩니다. MPI 장점은 32-512 CPU 클러스터가 32-512 CPU 단일 시스템보다 훨씬 저렴하다는 것입니다. 또한, MPI를 사용하면 알고리즘을 설계 할 때 비용이 선행 적입니다. OpenMP / UPC는 시스템이 NUMA를 사용하는 경우 (그리고 모든 대형 시스템이 사용하는 경우) 런타임시 가져올 대기 시간을 숨길 수 있습니다. 프로그램이 확장되지 않으며 이유를 파악하는 데 시간이 걸립니다.

• 이 주장을 이해하지만 Erlang vs. OpenMP에 왜 그런 내용이 적용되지 않습니까? Erlang에 문제가 계속 발생하지 않도록하려면 어떻게해야합니까? - Lorin Hochstein

이 기사는 실제로 그것을 잘 설명합니다. Erlang은 데이터 arround의 작은 부분을 보내고 MPI가 더 복잡한 것들을 훨씬 잘 수행 할 때 가장 좋습니다. 또한 Erlang 모델은 이해하기 쉽습니다 :-)

Erlang 대 MPI - 최종 결과 및 소스 코드