GPU Acceleration and Portability of the TRIMEG Code for Gyrokinetic Plasma Simulations using OpenMP

본 논문은 이 논문은 범용 OpenMP API를 사용하여 TRIMEG 자이로키네틱 플라즈마 시뮬레이션 코드를 GPU 아키텍처로 성공적으로 이식하였음을 제시하며, 하이브리드 MPI-OpenMP 병렬화 및 이온 온도 구배 모드 시뮬레이션을 통해 상당한 속도 향상과 검증된 물리적 정확성을 입증한다.

핵심

개요: 우주의 폭풍을 요리하기

별 내부의 날씨를 예측하려고 노력하는 모습을 상상해 보세요. 현실 세계에서 우리는 태양이나 핵융합로 안에 직접 온도계를 꽂아 넣을 수 없습니다. 너무 뜨겁고 혼란스럽기 때문입니다. 대신, 과학자들은 슈퍼컴퓨터를 사용하여 플라즈마(초고온의 전하를 띤 가스)의 "가상 시뮬레이션"을 실행합니다.

TRIMEG 코드는 이 플라즈마를 시뮬레이션하기 위한 매우 정교하고 구체적인 레시피입니다. 이 코드는 수십억 개의 작은 입자(폭풍 속의 개별 모래알과 같은)를 추적하여 이들이 어떻게 소용돌이치고, 충돌하며, 난류를 만들어내는지 관찰합니다. 문제는 이 레시피가 엄청나게 무겁다는 점입니다. 표준 컴퓨터(CPU)에서 이 코드를 실행하는 것은 숟가락 하나로 산을 옮기려는 것과 같습니다. 시간이 너무 오래 걸립니다.

목표: 저자인 조르조 다네리(Giorgio Danferi)는 GPU(그래픽 처리 장치)를 사용하여 이 과정을 가속화하고자 했습니다. CPU를 아주 똑똑하지만 한 번에 채소 하나만 다듬을 수 있는 '단 한 명의 숙련된 셰프'라고 생각한다면, GPU는 1만 명의 보조 셰프들이 동시에 채소를 다듬을 수 있는 주방과 같습니다. 이 논문은 그 한 명의 숙련된 셰프의 레시피가 어떻게 하면 1만 명의 보조 셰프 군단과 완벽하게 호환되어 작동하게 할 수 있는지, 그리고 이를 두 종류의 서로 다른 브랜드 주방(NVIDIA와 AMD) 모두에서 작동하게 만드는 방법에 관한 것입니다.

과제: "만능 번역기" 문제

저자는 번역을 위해 OpenMP라는 도구를 선택했습니다. OpenMP를 "이 레시피의 이 부분을 가져다가 GPU에게 전달해!"라고 컴퓨터에 명령하는 만능 번역기라고 생각하면 됩니다.

하지만 저자는 두 가지 주요 장애물에 부딪혔습니다.

1. "컴파일러" 결함: 코드를 번역하는 소프트웨어(컴파일러)가 완벽하지 않았습니다. 이는 마치 만능 번역기가 가끔 "소금"이나 "열기"라는 단어를 말하는 법을 잊어버리는 것과 같았습니다. 저자는 이 번역기의 특이한 성질에 맞추기 위해 코드의 일부를 다시 작성해야 했습니다. 예를 들어, 코드는 고급 "다형성"(형태나 정체성을 바꿀 수 있는 객체를 뜻하는 멋진 용어)을 사용했는데, GPU용 번역기들은 이 형태 변화를 이해하지 못했습니다. 그래서 저자는 이 형태들을 작동 가능한 딱딱한 상자 형태로 평평하게 만들어야 했습니다.
2. "교통 체증": 메인 컴퓨터(CPU)와 GPU(보조 셰프들) 사이에서 데이터를 이동시키는 것은 느립니다. 만약 재료를 주고받느라 계속 멈춰 서 있어야 한다면, 보조 셰프들은 아무것도 못 하고 놀게 됩니다. 저자는 모든 재료를 처음에 한 번만 GPU로 옮겨서, 재료를 끊임없이 실어 나르는 일이 없도록 코드를 재구성해야 했습니다.

해결책: 주방 구조 재편하기

NVIDIA와 AMD GPU 모두에서 코드가 실행되도록 하기 위해, 저자는 TRIMEG 코드에 일종의 "수술"을 가해야 했습니다.

• 지도의 평탄화: 코드는 입자가 어디에 있는지 찾기 위해 복잡한 지도를 사용했습니다. 이 지도는 마치 엉망진창인 서류 캐비닛과 같았습니다. 저자는 GPU가 길을 잃지 않고 즉시 읽을 수 있도록 이 지도를 하나의 직선 목록으로 평평하게 만들었습니다.
• "경쟁" 해결: 때때로 수천 명의 보조 셰프가 동시에 같은 화이트보드에 글을 쓰려고 하면, 서로의 글자를 덮어쓰게 됩니다("경쟁 상태"). 저자는 코드가 이런 작업을 수행하는 지점들을 찾아냈고, 모두가 각자의 차선에서 글을 쓰도록 수정했습니다.
• "원사이즈(One-Size-Fits-All)" 타협: 두 GPU 브랜드(NVIDIA와 AMD)가 사용하는 언어가 약간 다르기 때문에, 저자는 두 브랜드 모두에서 작동하는 단일 코드 버전을 만들어야 했습니다. 비록 그것이 한쪽 브랜드에 대해 절대적으로 가장 빠른 방식은 아닐지라도, 특정 메모리 할당 방식을 사용하는 등의 "우회책"을 사용했습니다.

결과: 효과가 있었는가?

저자는 두 가지 유명한 "테스트 케이스"(새 자동차를 위한 표준 운전 테스트와 같은 것)를 사용하여 새로운 GPU 버전을 기존 CPU 버전과 비교 테스트했습니다.

1. 사이클론 케이스: 플라즈마 난류를 단순화한 시뮬레이션입니다.
2. TCV-X21 케이스: 플라즈마의 가장자리를 포함하는 더 복잡하고 현실적인 시뮬레이션입니다.

결론:

• 속도: GPU 버전은 훨씬 빨랐습니다. 일부 테스트에서는 단일 머신에서 CPU 버전보다 거의 30배 더 빨랐습니다.
• 정확도: GPU의 결과는 CPU 결과와 거의 완벽하게 일치했습니다. "날씨 패턴"(에너지 성장 및 난류 구조)이 동일하게 나타났습니다.
• 이식성: 코드는 별도의 완전한 재작성 없이도 NVIDIA와 AMD 하드웨어 모두에서 성공적으로 실행되었습니다.

한계점 (제약 사항)

저자는 다음과 같은 한계점에 대해 솔직하게 밝히고 있습니다:

• "번역기"는 아직 완벽하지 않습니다: 이 GPU용 컴파일러(코드를 기계어로 바꾸는 소프트웨어)는 아직 성숙해가는 단계입니다. 때때로 CPU와 약간 다른 수학적 결과를 만들어낼 수 있으며, 이는 시간이 흐름에 따라 미세한 오차를 유발할 수 있습니다.
• 하드웨어 불일치: 만약 CPU 코어는 많지만 GPU는 하나뿐인 컴퓨터를 사용한다면, 한꺼번에 너무 많은 작업을 밀어 넣을 경우 GPU가 과부하될 수 있습니다. 저자는 최상의 결과를 얻으려면 얼마나 많은 "셰프"(MPI 프로세스)를 둘 것인지와 얼마나 많은 "보조 셰프"(GPU 스레드)를 활용할 것인지의 균형을 맞춰야 한다는 것을 발견했습니다.
• "마법의 탄환"은 없습니다: 입자 이동 부분은 엄청난 속도 향상을 이루었지만, 자기장 방정식을 푸는 것과 같은 시뮬레이션의 다른 부분들은 해당 부분을 GPU로 옮길 수 있는 도구가 아직 준비되지 않았기 때문에 여전히 CPU에서 실행됩니다.

요약

요약하자면, 이 논문은 공학적 창의성에 관한 이야기입니다. 저자는 무겁고 느리며 복잡한 시뮬레이션 코드를 가져와 현대적이고 강력한 그래픽 카드에서 실행되도록 성공적으로 가르쳤습니다. 저자는 소프트웨어 버그와 컴파일러의 제한이라는 지뢰밭을 헤쳐 나가며, 두 종류의 하드웨어에서 모두 작동하는 버전을 만들어냈고, 정확도를 잃지 않으면서도 핵융합 플라즈마를 훨씬 빠르게 시뮬레이션할 수 있음을 증명했습니다. 이는 비록 완전히 자동화되고 완벽한 번역을 향한 여정이 아직 끝나지 않았을지라도, 핵융합 에너지 연구를 더욱 효율적으로 만들기 위한 중요한 단계입니다.

기술 요약

기술 요약: OpenMP를 이용한 TRIMEG 코드의 GPU 가속화 및 이식성: 자이로키네틱 플라즈마 시뮬레이션

문제 정의
플라즈마 물리 시뮬레이션, 특히 토카막 핵융합 장치의 불안정성과 난류를 연구하는 데 사용되는 자이로키네틱(gyrokinetic) 모델은 계산 집약적이다. C1 유한 요소법(finite element method)과 비정형 삼각형 격자를 사용하는 고정밀 입자-격자(particle-in-cell, PIC) 솔버인 TRIMEG 코드는 현실적인 시뮬레이션을 위해 필요한 방대한 수의 입자(흔히 $10^7$에서 $10^8$개)로 인해 심각한 실행 시간 문제를 겪고 있다. 이 코드는 이미 다중 노드 병렬성을 위해 MPI를 채택하고 있으나, 입자 푸싱(particle pushing)과 격자-입자 간 연산(G2P)이 전체 실행 시간의 최대 80%를 차지하는 주요 병목 구간이다. 과제는 이러한 특정 "핫스팟"을 그래픽 처리 장치(GPU)를 사용하여 가속화하는 동시에, 다형성(polymorphism)과 파생 타입(derived types)을 포함하는 코드의 복잡한 객체 지향 구조를 유지하면서 서로 다른 하드웨어 아키텍처(특히 NVIDIA와 AMD) 간의 이식성을 확보하는 것이다.

방법론
본 연구는 OpenMP 오프로딩 API(버전 4.0 이상)를 사용하여 TRIMEG 코드를 GPU 아키텍처로 포팅하는 데 중점을 두었다. 방법론은 다음과 같다:

1. 대상 선택: 높은 산술 강도(arithmetic intensity)를 가지고 입자 간 의존성이 없는 입자 푸셔 커널과 관련 G2P 연산(pullback, 밀도 계산, 분포 함수 보간)을 주요 오프로딩 대상으로 식yle하였다.
2. 이식성을 위한 코드 재구조화: amdflang(AMD)과 nvfortran(NVIDIA) 모두의 컴파일러 제한을 극복하기 위해 상당한 수준의 재구조화가 필요했다. 주요 과제는 다음과 같다:
   • 다형성: 두 컴파일러 모두 GPU 타겟 영역 내에서의 class() 파생 타입과 타입 결합 프로시저(type-bound procedures) 처리에 어려움을 겪었다. 해결책으로 가능한 경우 비다형성 type() 선언을 사용하도록 코드를 리팩토링하였으며, 입자와 장(field) 클래스 간의 순환 의존성을 해결하기 위해 베이스/확장 클래스 계층 구조와 Fortran INCLUDE 지침을 사용하여 함수 본문을 복제하는 우회 방법을 구현하였다.
   • 동적 배열: 코드는 C++ 벡터를 모방한 커스텀 라이브러리를 동적 배열에 활용하고 있었다. GPU 커널은 동적 할당이나 복잡한 포인터 간접 참조를 쉽게 처리할 수 없으므로, 경계 상자(bounding box)와 메쉬 삼각형 사이의 매핑 구조를 배열 오브 스트럭처(array of structures)에서 1D 배열로 "평탄화(flattening)"하여 효율적인 메모리 전송을 용지하였다.
   • 메모리 관리: 런타임 지연 시간을 최소 최소화하기 위해 초기화 단계에서 선제적 메모리 할당을 구현하였다. AMD 플랫폼의 경우 통합 공유 메모리(Unified Shared Memory, USM)를 최대한 활용하였고, USM 지원이 부족한 NVIDIA 플랫폼의 경우 명시적인 enter data, update, exit data 지침을 사용하였다.
   • 수치적 일관성: GPU 결과가 CPU 참조 결과와 일치하도록, 부동 소수점 산술을 변경하는 컴파일러 최적화(예: Fused-Multiply-Add 명령)를 비활성화하였다(amdflang의 경우 -ffp-contract=off, nvfortran의 경우 -Mnofma). 외부 B-스플라인 라이브 library의 레이스 컨디션(race condition)은 공유 객체 멤버를 로컬에 선언된 자동 배열로 전환함으로써 해결하였다.
3. 성능 평가: 구현 결과는 Viper 클러스터(AMD MI300A), Raven(NVIDIA A100), Pitagora(NVIDIA H100) 클러스터에서 테스트되었다. 성능은 다음을 통해 평가되었다:
   • 커널 프로파일링: 자원 점유율, 메모리 대역폭, 명령어 혼합을 분석하기 위해 rocprof-compute 및 nsys를 사용하였다.
   • 확장성 연구: 하이브리드 MPI-OpenMP 오프로딩의 효율성을 평가하기 위해 강력한 스케일링(strong scaling) 테스트를 수행하였으며, 특히 여러 MPI 프로세스로 GPU를 오버서브스크라이빙(oversubscribing)하는 영향을 조사하였다.
   • 격자 크기 탐색: 하드웨어 활용도를 극대화하기 위해 OpenMP 팀(team) 수와 팀당 스레드 수를 튜닝하였다.

주요 기여

• 최초의 교차 벤더 포팅: 본 연구는 단일 코드베이스를 통해 OpenMP 오フロ딩을 사용하여 복잡한 객체 지향 Fortran 자이로키네틱 코드를 NVIDIA와 AMD GPU 모두에 포팅하는 선구적인 노력을 제시한다.
• 컴파일러 우회 기법: 다형성, 동적 배열, 프로시저 포인터에 대한 컴파일러 제한을 극복하기 위한 구체적이고 비자명한 우회 방법을 문서화하였다. 이는 nvfortran 및 amdflang의 이러한 기능에 대한 포괄적인 문서화가 부족함을 강조한다.
• 하이브리드 병렬화 분석: 하이브리드 MPI-OpenMP 오프로딩의 트레이드오프에 대한 상세한 분석을 제공하며, 입자 푸셔에 대해서는 GPU 가속이 효과적이지만, 원래 코드에 OpenMP 멀티스레딩이 부족하여 오버서크라이빙이 필요하며, 이것이 높은 코어 수를 가진 노드에서 GPU 자원이 제한될 때 스케일링을 제한할 수 있음을 보여준다.
• 수치 검증: 에너지 성장률과 2D 모드 구조를 CPU 결과와 비교하는 엄격한 검증 과정을 포함하여, 컴파일러 특유의 부동 소수점 처리에 따른 미세한 수치적 편차에도 불구하고 GPU 버전이 높은 충실도로 물리학을 재현함을 확인하였다.

결과

• 속도 향상: $32 \times 10^6$개의 전자를 포함한 실제 워크로드에 대해, GPU 구현은 TOK 클러스터의 GCC 컴령 CPU 버전 대비 AMD Viper 노드에서 약 14.8배, NVIDIA Pitagora 노드에서 약 29.6배의 속도 향상을 달いました.
• 커널 효율성: 입자 푸셔 커널이 실행 시간의 대부분을 차지했다. AMD MI300A에서의 프로파일링 결과, 높은 산술 강도와 80% 이상의 L1/L2 캐시 적중률을 보였으나, 메모리 액세스의 18%만이 병합(coalesced)되었다.
• 확장성 제한: 강력한 스케일링 테스트 결과, GPU 가속 부분이 잘 확장되는 반면, 전체 애플리케이션의 속도 향상은 비가속 부분(예: PETSc를 사용하는 필드 솔버)과 GPU 오버서크라이빙의 오버헤드에 의해 제약을 받는 것으로 나타났다. NVIDIA Pitagora 클러스터의 경우, 테스트된 컴파일러 버전(nvfortran 24.9)에서 OpenMP를 통한 멀티 GPU 지원이 작동하지 않아, 노드 내의 모든 가용 GPU를 동시에 활용하는 능력이 제한됨을 발견하였다.
• 정확성: Cyclone 케이스(ITG 모드) 및 TCV-X21 케이스(비선형 ITG 불안정성) 시뮬레이션을 통해, GPU 버전이 에너지 성장률과 모드 구조를 CPU 버전과 동일하게 정확히 재현함을 확인하였다. 차이점은 알고리즘 오류가 아닌 난수 생성기 초기화 및 컴파일러별 부동 소수점 변동에 기인한다.

의의 및 주장
본 논문은 OpenMP 오프로딩이 서로 다른 HPC 아키텍처 간의 이식성을 위한 유망한 경로를 제공하지만, 복잡한 레거시 코드에 있어서는 "심리스(seamless)"한 솔루션이 아님을 주장한다. 본 연구는 작동하고 고성능을 내는 GPU 버전을 구축하기 위해서는 고급 Fortran 기능에 대한 광범위한 컴파일러 탐색과 상당한 코드 재구조화가 필요함을 입증한다.

저자들은 이러한 이식성의 성공이 단순히 프로그래밍 패러다임뿐만 아니라 특정 컴파일러 버전에 크게 의존한다는 점을 강조한다. 결론적으로, TRIMEG GPU 구현은 가장 계산 집약적인 부분에 대해 상당한 속도 향상을 제공할 수 있는, 자이로키네틱 시뮬레이션을 위한 기능적이고 정확한 도구임을 밝힌다. 다만, 하드웨어의 잠재력(특히 멀티 GPU 노드)은 현재 멀티 디바이스 오프로딩에 대한 미성숙한 컴파일러 지원과 기반 CPU 코드 구조의 OpenMP 멀티스레딩 부재로 인해 제한되고 있다고 겸허히 언급한다. 본 연구는 이종 아키텍처로 복잡한 Fortran 코드를 포팅하려는 다른 이들에게 실질적인 가이드이자 "대체 문서(surrogate documentation)" 역할을 한다.