향후 페타 스케일 머신에서 코드를 실행하려면 어떤 프로그래밍 패러다임에 투자해야합니까?

업계가 처리 코어 가 기하 급수적으로 증가 하는 추세에있는 것으로 나타났습니다 . 가장 큰 수퍼 컴퓨터는 모두 노드 간 통신에 MPI를 사용하지만 단일 MPI 프로세스를 각 코어에 자동으로 매핑하는 가장 간단한 (그러나 가장 효율적인 것은 아니지만) 노드 간 병렬 처리에 대한 명확한 추세는 보이지 않습니다. 컴파일러, OpenMP, pthreads, CUDA, Cilk 및 OpenCL의 병렬화

저는 세계에서 가장 큰 슈퍼 컴퓨터 중 일부에서 사용될 수있는 코드를 유지하고 개발하는 과학자 그룹 중 하나입니다. 유한 한 개발자 시간을 가정하면, 세계에서 가장 강력한 머신의 성능을 활용할 수 있도록 미래를 어떻게 보장합니까? 프로세스 인터커넥트 아키텍처에 대해 어떤 가정을해야합니까? 많은 시대에 접어 들면서 어떤 패러다임이 겪을 것입니까? 페타 스케일 시스템에서 파티션 된 전체 주소 공간 언어를 "제작 중"으로 사용할 수 있습니까?

역사적 관점

미래에 새로운 패러다임이 어떻게 될지 말하기는 불가능합니다. 예를 들어 Ken Kennedy의 Rise and Fall of HPF를 읽는 것이 좋습니다 . Kennedy는 MPI와 스마트 컴파일러의 두 가지 새로운 패턴에 대해 설명하고 MPI가 어떻게 초기 얼리 어답터를 적절하게 지배하고 유연성을 발휘했는지 자세히 설명합니다. HPF는 결국 문제를 해결했지만 너무 늦었습니다.

여러 가지면에서 PGAS 및 OpenMP와 같은 여러 패러다임이 동일한 HPF 추세를 따르고 있습니다. 초기 코드는 유연하게 사용할 수 없었으며 테이블에서 많은 성능을 남겼습니다. 그러나 병렬 알고리즘의 모든 iota를 작성할 필요가 없다는 약속은 매력적인 목표입니다. 따라서 항상 새로운 모델을 추구하고 있습니다.

하드웨어의 명확한 추세

이제 MPI의 성공은 종종 그것이 실행되는 하드웨어를 모델링하는 방법과 밀접한 관련이 있다고 언급되었습니다. 대략 각 노드에는 몇 개의 프로세스가 있으며 메시지를 로컬 지점 간 또는 조정 된 일괄 작업을 통해 클러스터 공간에서 쉽게 전달할 수 있습니다. 이 때문에 새로운 하드웨어 트렌드를 따르지 않는 패러다임을주는 사람을 믿지 않습니다. 실제로 Vivak Sarakar 의 연구를 통해이 의견을 확신 했습니다 .

이를 유지하기 위해 새로운 아키텍처로 나아가는 세 가지 트렌드가 있습니다. HPC 에는 현재 12 개의 서로 다른 아키텍처가 판매되고 있습니다. 5 년 전만해도 x86 만 제공되므로 앞으로는 다양하고 흥미로운 방법으로 하드웨어를 사용할 수있는 많은 기회를 보게 될 것입니다

• 특수 목적 칩 : 가속기와 같은 큰 벡터 장치를 생각하십시오 (Nvidia의 Bill Dally가지지 함).
• 저전력 칩 : ARM 기반 클러스터 (전력 예산을 수용하기 위해)
• 칩 타일링 : 사양이 다른 칩 타일링을 생각하십시오 ( Avant Argwal의 작품 )

현재 모델

현재 모델의 깊이는 실제로 3 단계입니다. 이러한 레벨 중 두 가지를 사용하는 코드는 많지만 세 가지를 모두 사용하는 코드는 많지 않습니다. 먼저 엑사 스케일에 도달하려면 코드가 세 가지 레벨 모두에서 실행될 수 있는지 결정하는 데 투자해야한다고 생각합니다. 이것은 현재 추세를 잘 반복 할 수있는 가장 안전한 경로 일 것입니다.

예측 된 새 하드웨어 뷰를 기반으로 모델과 모델 변경 방법에 대해 반복하겠습니다.

분산

분산 수준의 플레이어는 주로 MPI 및 PGAS 언어에 속합니다. MPI는 현재 확실한 승자이지만 UPC 및 Chapel과 같은 PGAS 언어는 우주로 향하고 있습니다. 좋은 지적 중 하나는 HPC 벤치 마크 챌린지입니다. PGAS 언어는 매우 우아한 벤치 마크 구현을 제공합니다.

여기서 가장 흥미로운 점은이 모델이 현재 노드 수준에서만 작동하지만 Tiled 아키텍처의 경우 노드 내부에서 중요한 모델이 될 것입니다. 기본적으로 분산 시스템처럼 작동하는 Intel SCC 칩이 있습니다. SCC 팀은 자체 MPI 구현을 만들었으며 많은 팀이 커뮤니티 라이브러리를이 아키텍처로 이식하는 데 성공했습니다.

그러나 솔직히 말해서 PGAS는 실제로이 분야에 뛰어 들기위한 좋은 이야기가 있습니다. 실제로 MPI 인터 노드를 프로그래밍하고 동일한 트릭 인트라 노드를 수행해야합니까? 이러한 타일 구조의 한 가지 큰 문제는 칩에서 클럭 속도가 다르고 메모리 대역폭에 큰 차이가 있으므로 성능 코드가이를 고려해야한다는 것입니다.

온 노드 공유 메모리

여기서는 MPI가 종종 "충분히 좋은"것으로 보이지만 PThreads (및 Intel Parallel Building Blocks와 같은 PThread에서 파생 된 라이브러리) 및 OpenMP는 여전히 자주 사용됩니다. 일반적인 관점은 MPI의 소켓 모델이 RPC에 대해 분류 할 공유 메모리 스레드가 충분할 때가 있거나 코어에서 더 가벼운 프로세스가 필요하다는 것입니다. 이미 공유 메모리 MPI에 문제가있는 IBM Bluegene 시스템의 표시를 볼 수 있습니다.

Matt가 언급했듯이 계산 집약적 코드의 최대 성능 향상은 직렬 코드의 벡터화입니다. 많은 사람들이 액셀러레이터에서 이것이 사실이라고 가정하지만 온 노드 시스템에도 중요합니다. Westmere에는 4 개의 넓은 FPU가 있다고 생각하므로 벡터화 없이도 1/4의 플롭을 얻을 수 있습니다.

현재 OpenMP 가이 공간으로 잘 들어가는 것을 보지 못하지만 저전력 또는 타일 칩이 더 가벼운 스레드를 사용할 수있는 곳이 있습니다. OpenMP는 데이터 흐름이 작동하는 방식을 설명하는 데 어려움을 겪고 있으며 더 많은 스레드가 사용됨에 따라이 추세가 과장된 것을 볼 수 있습니다. OpenMP를 사용하여 적절한 프리 페치를 얻기 위해 수행해야하는 작업의 예를 살펴보십시오.

물론 충분한 수준의 OpenMP 및 PThreads는 피크의 비율을 높이는 데 필요한 벡터화를 활용할 수 있지만 그렇게하려면 벡터화가 자연스럽게 알고리즘을 분해해야합니다.

코 프로세서

마지막으로 코 프로세서 (GPU, MIC, Cell acclerators)의 출현이 막을 내렸다. 엑 사스케 일로가는 길은 그들 없이는 완성 될 수 없다는 것이 분명 해지고 있습니다. SC11에서는 모든 Bell 상을 수상한 참가자들이 페타 플롭이 낮은 곳까지 매우 효과적으로 사용했습니다. CUDA와 OpenCL이 현재 시장을 지배하고 있지만 OpenACC 및 PGAS 컴파일러가이 시장에 진입하기를 희망합니다.

엑사 스케일에 도달하기 위해, 하나의 제안은 저전력 칩을 많은 코 프로세서에 결합하는 것이다. 이것은 현재 스택의 중간 계층을 제거하고 메인 칩의 의사 결정 문제를 관리하고 코 프로세서로의 작업을 섞는 코드를 사용합니다. 이것은 코드가 매우 효과적으로 작동하기 위해서는 커널 (또는 코드 렛) 측면에서 알고리즘을 다시 생각해야한다는 것입니다. 내가 아는 한,이 진화에 대한 해결책은 꽤 넓습니다.

이것이 앱 개발자에게 미치는 영향

이제 귀하의 질문에 도달하십시오. 다가오는 엑사 스케일 머신으로부터 자신을 보호하려면 몇 가지 작업을 수행해야합니다.

• 3 단계 이상의 병렬 계층 구조에 맞도록 알고리즘을 개발하십시오.
• 계층 구조간에 이동할 수있는 커널 측면에서 알고리즘을 설계하십시오.
• 순차적 프로세스에 대한 필요성을 완화하십시오. 동기식 실행이 불가능하기 때문에 이러한 모든 효과는 비동기식으로 발생합니다.

오늘 공연을하고 싶다면 MPI + CUDA / OpenCL만으로도 충분하지만 UPC는 며칠이 걸리고 배우는 나쁜 생각이 아닙니다. OpenMP를 시작하면 코드를 리팩터링해야하는 문제가 발생합니다. PThreads는 코드를 스타일에 맞게 완전히 다시 작성해야합니다. MPI + CUDA / OpenCL을 현재 최고의 모델로 만듭니다.

여기서 다루지 않은 것

엑사 스케일에 대한이 모든 이야기는 훌륭하지만 여기서 실제로 논의되지 않은 것은 머신에 데이터를주고받는 것입니다. 메모리 시스템에 많은 발전이 있었지만, 우리는 상품 클러스터에서 그것들을 보지 못했습니다 (너무 비싸다). 이제 데이터 집약적 컴퓨팅이 모든 슈퍼 컴퓨팅 컨퍼런스의 큰 초점이되고 있으므로 높은 메모리 대역폭 공간으로의 이동이 더 커질 것입니다.

이로 인해 발생할 수있는 다른 추세가 발생합니다 (적절한 자금 지원 기관이 관여하는 경우). 기계는 필요한 컴퓨팅 유형에 점점 더 전문화 될 것입니다. 우리는 이미 NSF가 "데이터 집약적 인"머신에 자금을 지원하고 있지만이 머신은 2019 Exascale Grand Challenge와는 다른 트랙에 있습니다.

이것은 주석에서 필요한 참조를 요청하는 것보다 오래되었습니다.

MPI가 노드 간 코드에 적합한 선택이라고 생각하기 때문에 노드 내 코드 (인터커넥트에 닿지 않는 컴퓨팅)에 대한 전략을 논의하는 것으로 시작하겠습니다. 코어가 100 개 미만인 노드, 즉 현재 GPU 또는 MIC에 대해서는 말할 필요가 없다고 생각합니다.

pthreads만으로는 현대적인 칩에서 최대 성능을 얻을 수 없다는 사실은 벡터 장치를 활용해야하기 때문입니다 (첫 번째 Cray 이후 참). 인텔과 AMD에서는 내장 함수를 사용할 수 있지만 이것들은 이식성이 없으며 내 의견으로는 어수선합니다. CUDA와 OpenCL에는 라이브러리에 벡터화 기능이 내장되어있어 최대 성능을 쉽게 얻을 수 있습니다. 내가 알고있는 모든 새로운 하드웨어에는이 벡터 요구 사항이 있으므로 모든 솔루션에서이를 고려해야합니다. 저에게는 CUDA / OpenCL이 현재 진행되고 있습니다.

다음으로이 모든 머신은 NUMA가되어 프로그래밍하기가 어렵지만 커널 전략이 효과가 있다고 생각합니다. 작업과 데이터를 작은 단위로 나눕니다. CUDA 및 OpenCL에서 현재 발생하는 것처럼 자동으로 예약되지만 종속성을 지정할 수 있습니다. 스트리밍 패러다임에 맞는 문제의 경우이 청킹을 자동으로 수행 할 수도 있습니다. Intel TBB는이를 수행하지만 CUDA 또는 (곧) TBB를 대상으로 할 수있는 Thrust 및 Cusp로 예시 된 고급 라이브러리 접근 방식을 선호합니다 .

이 스레드에서 존경받는 동료들보다 짧은 답변을 시도합니다. ;-)

모든 학생들에게 보내는 메시지는 항상 개발자 시간이 CPU 시간보다 더 중요하다는 것입니다. 즉, 높은 수준의 접근 방식을 사용하여 큰 기계에서 실행하기 위해 코드의 100 %를 80 % 효율로 변환 할 시간이 있다면 시간이 많이 걸리는 저수준을 사용할 때보 다 더 나은 방법입니다 코드의 20 %에서 100 % 효율성을 제공하는 접근 방식. 결과적으로 저는 고급 라이브러리를 좋아합니다. 이 영역에서 내가 가장 좋아하는 것은 스레딩 빌딩 블록 (TBB)입니다. 왜냐하면 가장 바깥 쪽 루프와 높은 수준에서 알고리즘을 볼 수 있기 때문입니다. 또한 OS 함수 등을 다루지 않아도되므로 pthread로 할 수있는 모든 작업을 수행 할 수 있습니다. 노드 내 병렬 리소스를 악용하기에는 잘못된 수준이기 때문에 가장 안쪽 루프를 보는 방식의 팬이 아닙니다. -OpenMP가 없습니다.

OpenCL, CUDA 등에 대한 권한으로 말할 수 없습니다.

이전에 게시 된 답변은 훌륭하지만 대부분 노드 아키텍처에 중점을 두었습니다. 이는 MPI가 일반적으로 대부분의 경우 노드 간 프로그래밍 모델로 충분하다고 간주되고 우리가 어려움을 겪는 경우 노드 내 병렬 처리 라는 사실을 반영한다고 생각합니다 .

다음은 비교적 제한적으로 답변되지 않은 두 가지 질문에 대한 나의 시도입니다.

프로세스 인터커넥트 아키텍처에 대해 어떤 가정을해야합니까?

네트워크의 세 가지 속성을 고려할 것입니다.

1. 지연 시간,
2. 대역폭
3. 동시성.

지연 시간은 주파수에 반비례합니다. 주파수 스케일링이 정체되었음을 알고 있습니다. 따라서 향후 대기 시간이 크게 줄어들지 않을 것이라고 결론을 내릴 수 있습니다. Blue Gene / Q의 MPI send-recv 대기 시간은 약 2 us이며 이는 3200주기에 해당합니다. 이 대기 시간의 절반 이상이 소프트웨어이지만 MPI 표준에는 상당 부분이 필요합니다. 광범위한 튜닝은 특히 MPI 와일드 카드를 사용하지 않을 것이라고 주장 할 수있는 경우 대기 시간을 1 us에 가깝게 줄일 수 있습니다.

어쨌든 Blue Gene 및 Cray 시스템에서 패킷 주입을위한 하드웨어 대기 시간은 약 1 us입니다. 어쨌든 노드 수준의 동시성을 늘리면이 수를 너무 낮게 유지하는 것이 어려워 지지만 하드웨어 디자이너는 가까운 시일 내에 대기 시간을 5 미만으로 유지할 방법을 찾게 될 것입니다.

네트워크 링크 수를 늘리면 네트워크 대역폭이 크게 증가합니다. 그러나 이것은 이야기의 일부일뿐입니다. 하나는 노드에 1000 개의 아웃 바운드 링크를 넣고 프로세서가 네트워크를 전체 대역폭으로 구동 할 수없는 경우이를 사용할 수 없습니다. 예를 들어, 일부 슈퍼 컴퓨터는 주입 대역폭 측면에서 네트워크가 아닌 버스 (예 : HyperTransport)에서 병목 현상을 일으 킵니다.

네트워크 대역폭에 대한 기본 제한은 없으며 실제 제한 만 있습니다. 대역폭은 비용과 전력이 필요합니다. 시스템 설계자는 미래의 시스템을 개발할 때 네트워크 대역폭과 기계의 다른 부분 간의 균형을 고려해야합니다. 많은 코드가 네트워크 대역폭에 제한이 없으므로 향후 연결 당 대역폭이 훨씬 더 많은 시스템을 볼 수 없을 것 같습니다. 그러나 노드 당 대역폭은 컴퓨팅 성능에 비례하여 증가해야하므로 확장하려면 노드 당 여러 개의 연결이 필요합니다.

공식적인 모델에서 종종 간과되는 네트워크의 세 번째 속성은 한 번에 보낼 수있는 메시지 수입니다. 한 번에 1 개의 메시지 만 보낼 수있는 1ns의 대기 시간 및 / 또는 1TB / s 대역폭의 네트워크가 있으면 대부분의 용도에 전혀 쓸모가 없습니다. 많은 스레드에서 동시에 많은 메시지를 보내고 네트워크가 경합 상태에서 붕괴되지 않도록하는 것이 중요합니다. Cray 및 Blue Gene 시스템은 이제 1 MMPS (초당 백만 메시지)를 초과합니다. 정확한 숫자를 기억할 수는 없지만 두 메시지 모두 작은 메시지로 피크 대역폭의 상당 부분을 달성 할 수 있습니다. 이상적인 네트워크는 모든 크기의 메시지로 최대 대역폭에 도달 할 수 있지만 실제로는 패킷 헤더 및 관련 부기 오버 헤드로 인해 불가능합니다. 하나,

이것은 불완전하고 불완전한 대답입니다. 다른 사람들은 그것을 향상 시키려고 노력하거나 개선해야 할 것을 제안 할 수 있습니다.

페타 스케일 시스템에서 파티션 된 전체 주소 공간 언어를 "제작 중"으로 사용할 수 있습니까?

Cray XE, XK 및 XC 시스템에는 프로덕션 품질의 UPC 및 CAF 컴파일러가 있습니다. Blue Gene 시스템은 XLUPC 및 XLCAF와 함께 제공 될 수 있지만 아무도이를 요구하지 않으므로 전달되지 않습니다. PERCS에는 프로덕션 급 XLUPC 및 XLCAF 컴파일러가 있지만 과학 커뮤니티에서 액세스 할 수있는 대규모 설치는 없습니다.

Coarrays는 Fortran 2008의 일부이지만 Intel 및 GNU Fortran의 구현은 아직 고품질이 아닙니다. 인텔 구현은 작동하는 것으로 유명하지만 속도가 느립니다 (PGAS12에는 이에 관한 논문이 있습니다).

PGAS 프로그래밍 모델 (프로그래밍 언어가 아닌 프로그래밍 모델은 원래 질문의 대상이므로)이므로 Global Arrays 라이브러리는 많은 경우 생산 품질에 대한 합리적인 근사치입니다. 런타임으로서 MPI만큼 강력하지는 않지만 MPI는 구현 품질의 측면에서 매우 독창적입니다. ARMCI의 ARMCI-MPI 구현은 경우에 따라 속도가 느리더라도 글로벌 어레이를 훨씬 더 안정적으로 만듭니다.

MPI-3 RMA를 사용하여 프로덕션 품질 방식으로 PGAS 스타일 구성을 구현하는 것이 상대적으로 쉽습니다. 누군가가 이것에 관한 새로운 질문을 게시하면 기꺼이 대답 할 것입니다.

실제로 방대한 양의 코어는 사소하지만 놀랍도록 유용한 관점을 열어줍니다.이를 사용하여 전체 시뮬레이션을 여러 번 반복 할 수 있습니다.

오늘날 전산 연구의 중요한 부분은 일부 매개 변수 공간을 스캔하고 초기 조건의 큰 풀을 스크리닝하거나 일부 결과의 분포를 리샘플링 방식으로 계산하는 것으로 요약됩니다. 이러한 모든 작업은 당황스럽게 평행하므로 Amdahl-proof입니다.

나는이 질문에 대해 가장 잘 생각 된 답변조차 5 년에서 10 년 안에 쓸모 없게 될 것이라고 생각합니다. 미래 프로그래밍 패러다임의 불확실성을 감안할 때 코드베이스를 사전 최적화하는 데 많은 시간을 소비하는 것은 가치가 없을 수 있습니다.

나는 이 질문 에이 답변을 게시 하려고했지만 이 질문 의 복제본으로 닫혔으므로 다음으로 이동하십시오.

솔로 닉이 약간 들릴지 모르지만 미래에는 멀티 스레드 커널을 실행하는 여러 공유 메모리 멀티 코어 노드가 MPI와 같은 분산 메모리 패러다임을 통해 연결된 하이브리드 방식에 속합니다 .

그러나 몇 가지 문제가 있으며 하드웨어와 전혀 관련이 없습니다. 우선, 대부분의 병렬 프로그래머는 MPI 유형 코드에 많은 투자를하고 있으며 새로운 패러다임을 사용하여 코드 기반의 일부 또는 전부를 처음으로 구현하는 것을 꺼려합니다. 공유 메모리 접근 방식을 사용하는 사람들이 없기 때문에 해당 영역에 대한 알고리즘의 진행이 느려져 투자가 더욱 의미없는 것처럼 보입니다.

두 번째 문제는 모든 사람이 공유 메모리 병렬 처리를 OpenMP 와 연관시키는 것 입니다. OpenMP는 적은 수의 프로세서에서 작고 간단한 문제를 해결하기위한 빠르고 쉬운 방법이지만 실제 공유 메모리 병렬 처리를 위한 끔찍한 프로그래밍 모델입니다 . 비록 우리가 어느 시점에서나 여러 가지 단순하고 효율적인 병렬 프로그래밍 패러다임 (예 : Thread pools 또는 Scheduler )을 배웠지 만 OpenMP를 사용하여 구현하기 쉽지 않으며 솔직히 말해서 이것은 병렬 처리의 유형이 아닙니다. OpenMP는 프로그래머가 사용하도록 유혹합니다.

요약하면, 순수하게 분산 된 메모리에서 순수 / 부분적으로 공유 된 메모리 패러다임으로의 이동에 대한 장벽은 상당히 높습니다. 스레드를 효율적으로 사용하려면 OpenMP를 잊고 스레드와 동시성을 직접 관리해야합니다 (hello pthreads , goodbye Fortran).

그러나 왜 하이브리드 방식으로 전환해야합니까? MPI는 수천 개의 코어로 확장되지만 기본 모델은 잠금 단계 동기화 및 정적 통신 패턴 중 하나입니다. 이는 10 억 입자 시뮬레이션과 같은 일부 문제에는 유용하지만 더 어렵거나 세밀한 문제에는 차선책입니다. 공유 메모리 패러다임을 통해 동적로드 밸런싱 및 / 또는 비동기 통신이 훨씬 쉬워 지지만 주요 프로그래밍 노력이 필요합니다.