Scientific Computing의 작업 기반 공유 메모리 병렬 라이브러리

최근 몇 가지 형태의 범용 데이터 중심 공유 메모리 병렬 처리를 제공하는 여러 라이브러리 / 소프트웨어 프로젝트가 등장했습니다.

주요 아이디어는 프로그래머가 명시 적으로 스레드 된 코드를 작성하는 대신 알고리즘을 상호 종속적 인 작업으로 구현 한 다음 공유 메모리 시스템의 범용 미들웨어에 의해 동적으로 스케줄됩니다.

이러한 라이브러리의 예는 다음과 같습니다.

QUARK : 원래 MAGMA 병렬 선형 대수 라이브러리를 위해 설계되었으며 병렬 고속 다중 극 방법 에도 사용 된 것으로 보입니다 .
Cilk : 원래 Intel에서 지원하는 MIT 기반 프로젝트는 Cilkchess 컴퓨터 체스 소프트웨어에서 실험적으로 FFTW에서 사용되는 C 언어 확장 프로그램으로 구현되었습니다 .
SMP 슈퍼 스칼라 : #pragma확장을 기반으로 여러 측면에서 Cilk와 유사한 Barcelona Supercomputing Center에서 개발되었습니다 .
StarPU : GPU를 포함하여 여러 가지 다른 아키텍처에서 컴파일 및 예약 할 수있는 유사한 라이브러리 기반 "codelet"입니다.
OpenMP 작업 : 버전 3.0부터 OpenMP는 비동기식으로 예약 할 수있는 "작업"을 도입했습니다 (사양 2.7 절 참조).
인텔의 스레딩 구성 요소 : C ++ 클래스를 사용하여 비동기 작업을 생성 및 시작합니다 (자습서 11 장 참조).
OpenCL : 멀티 코어에서 작업 기반 병렬 처리를 지원합니다.

이 라이브러리 / 언어 확장의 내부 작업과 특정 문제에 대한 응용 프로그램을 설명하는 문헌이 많이 있지만 과학 컴퓨팅 응용 프로그램에서 실제로 사용되는 예제는 거의 없습니다.

그래서 여기에 대한 질문이 있습니다 : 공유 메모리 병렬 처리를 위해 이러한 라이브러리 / 언어 확장 또는 이와 유사한 것을 사용하는 과학 컴퓨팅 코드를 아는 사람이 있습니까?

— 페드로
소스

작업 기반 병렬 처리를 찾고 있습니까? OpenCL과 Intel TBB를 건너 뛴 이유가 있습니까? 나는 당신이 찾고있는 것을 정확하게 말할 수 없다는 것을 인정해야합니다.

— Aron Ahmadia

@AronAhmadia : 무지, 주로 ... :) TBB와 OpenCL을 목록에 추가했지만 질문은 여전히 동일합니다. 이러한 작업, 즉 작업 기반 구성 요소가 과학을 위해 중요한 소프트웨어에서 사용 되었습니까? 컴퓨팅?

— 페드로

우리는이 질문과 그 답변을 커뮤니티 위키로 바꾸는 것에 대해 어떻게 생각합니까?

— Aron Ahmadia

@ AronAhmadia : 질문 형식을 벗어나면 일반적으로 작업 기반 및 / 또는 공유 메모리 프로그래밍의 장점 / 단점에 대한 긴 토론으로 빠르게 퇴보 될 것이라고 조금 걱정됩니다. 그러나 몇 가지 추가 답변을 얻은 후에 전환하는 것을 선호합니다.

— 페드로

제목이 적절하지 않습니다. 이 질문은 공유 메모리가 아닌 작업 병렬 처리에 관한 것입니다.

— Jeff

답변:

deal.II 는 라이브러리 전체에서 스레딩 빌딩 블록을 사용하며 전반적으로 우리는 합리적으로 만족합니다. 우리는 몇 가지 대안, 특히 OpenMP가 더 간단한 코드를 위해 그것을 사용하는 것처럼 보이지만 그것들이 부족하다는 것을 발견했기 때문에 OpenMP를 살펴 보았습니다. 특히, OpenMP는 작업 모델을 사용하여 시작한 작업에 대한 핸들을 얻을 수 없으므로 작업 상태에 액세스 (예 : 작업이 완료되기를 기다리거나)의 값을 반환하기가 어렵다는 큰 단점이 있습니다. 별도의 작업에서 실행되는 기능. OpenMP는 주로 가장 안쪽의 루프 를 병렬화하는 데는 좋지만 가장 바깥 쪽 의 복잡한 루프 를 병렬화하여 병렬 효율성을 얻을 수 있으며 OpenMP는이를위한 도구가 아니며 TBB는 그에 적합합니다.

— 볼프강 뱅 거스
소스

이것을 지적 해 주셔서 감사합니다, 나는 거래를 보지 않았습니다 .II! II. TBB 사용에 대해 자세히 설명하는 출판물이나 문서가 있습니까?

— 페드로

없음 게시,하지만이 5 월 도움말 : dealii.org/developer/doxygen/deal.II/group__threads.html

— 볼프강 Bangerth

제 생각에는 이러한 시스템은 주로 다음과 같은 이유로 인해 실패했습니다.

병렬 계산은 메모리 위치를 노출하고 동기화 지점을 제거하는 것보다 계산을 병렬화하는 것 (예 : 플롭)에 대한 순진한 관점입니다. 밀도가 높은 매트릭스 알고리즘과 같은 일부 문제는 여전히 FP로 제한되지만 메모리 하위 시스템을 신중하게 고려한 후에 만 발생하며 대부분의 계산 커널 (특히 PDE 세계)은 메모리에 더 민감합니다. 작업 대기열은 플롭의보다 순진한 균형과 더 많은 원자 메모리 작업을 위해 메모리 대기열을 교환하는 경향이 있습니다 (대기열을 통한 동기화로 인해).
강력한 확장 성을 희생하면서 동적로드 밸런싱을 위해 과도한 분해에 의존 작업에는 일반적으로 겹치는 데이터 종속성 (고스트 값)이 있습니다. 내부 크기가 줄어들면 고스트 / 인테리어 비율이 증가합니다. 이것이 중복 작업을 의미하지 않더라도 증가 된 메모리 이동을 의미합니다. 이웃에 대한 소프트웨어 프리 페치 (여러 스레드 그룹을 대략적으로 일관성있게 유지)하여 여러 스레드가 L1 또는 L2 캐시를 공유하는 협력 프리 페치와 같은 접근 방식으로 메모리 대역폭 요구 사항을 대폭 줄일 수 있습니다. 이것은 과분 해의 반대입니다.
위의 메모리 관련 문제로 인해 예기치 않은 성능이 발생했습니다.
라이브러리 친화적 인 구성 요소가 부족합니다. 이것은 MPI_Comm서로 다른 라이브러리가 충돌없이 풍부한 작업을 수행하고 라이브러리 간의 컨텍스트를 전달하고 필요한 속성을 복구 할 수 있는 유사체를 갖지 않는 것으로 요약 될 수 있습니다 . "커뮤니케이터"가 제공하는 추상화는 공유 또는 분산 메모리 사용 여부에 관계없이 라이브러리 구성에 중요합니다.

— 제드 브라운
소스

나는 당신의 대답을 오해 할 수도 있지만 첫 번째 요점은 Buttari, Kurzak, Dongarra 및 다른 사람들이 조밀 한 선형 대수학을위한 작업 기반 공유 메모리 라이브러리 인 MAGMA를 사용하여 보여준 것과 정확히 반대입니다. 중복 된 데이터, 즉 고스트 값과 표면 대 체적 비율을 나타내지 만 분산 메모리 도메인 분해 체계의 보류입니다. 본인은 입자 기반 코드에 대해 이러한 방법을 사용하며 MPI 기반 병렬 구현보다 훨씬 더 나은 성능을 얻습니다.

— 페드로

어쨌든 그 질문은 다른 것이 었습니다 ... 당신은 이러한 접근법을 사용하는 과학적 컴퓨팅 소프트웨어 프로젝트를 알고 있습니까?

— 페드로

1.이 시스템을 사용하는 소수의 프로젝트가 있지만 접근 방식이 "성공적"이라고 생각할 수는 없습니다. 2. 종속성이 여전히 공유 메모리에서 겹칩니다. tcmalloc 또는 Linux 커널이 원자를 통한 동기화와 같은 병목 현상을 피하기 위해 스레드를보다 독립적으로 만드는 방법을 살펴보십시오. 공유 주소 공간은 메모리가 균일하거나 원자가 저렴하다고 생각해야한다는 의미는 아닙니다.

— Jed Brown

3. 어떤 "공정한 비교"를 인용하려고하는지 모르겠지만 PLASMA는 최고 FPU의 약 25 % 만 얻습니다 (예 : hpcgarage.org/cscads2012/Luszczek-UTK-PowerTools.pdf의 슬라이드 5 ). 최대 70 %의 피크가 예상되는 분산 메모리에서 동일한 작업에 대해 의심 할 여지없이 나쁜 것입니다. 고밀도 선형 대수학은 가능한 예외로 구체적으로 언급 한 FPU 바운드 사례이지만, 엄청난 행렬 크기에도 불구하고 PLASMA는 FPU 바운드와는 거리가 멀습니다.

— Jed Brown

입자 (PPPM, 와류 입자 등)를 상기 표면 투 solume 효과의 대상이되는 업데이트와 결합되도록 페드로 대부분 물리학, 장거리 성분을 갖는다

— 매트 Knepley