Evaluating SYCL as a Unified Programming Model for Heterogeneous Systems

이 논문은 HPC 애플리케이션 개발자의 관점에서 SYCL 의 이식성, 생산성 및 성능을 평가하고, 다양한 구현체 간의 일관성 부족과 한계를 지적하며 향후 개선 방향을 제시합니다.

핵심

🌍 핵심 비유: "만능 여행 가이드 (SYCL)"의 실패와 희망

상상해 보세요. 당신은 전 세계를 여행하고 싶지만, 각 나라마다 언어, 교통수단, 통화가 다릅니다.

• 미국 (CPU): 영어를 쓰고, 차를 타고 다닙니다.
• 일본 (GPU): 일본어를 쓰고, 전철을 타고 다닙니다.
• 독일 (FPGA): 독일을 쓰고, 기차를 타고 다닙니다.

기존에는 여행자가 각 나라에 맞춰서 별도의 가이드북을 따로 만들어야 했습니다. (코드를 각각 다 짜야 함)

SYCL은 이 문제를 해결하기 위해 등장한 **"하나의 가이드북 (단일 소스 코드)"**입니다. "이 가이드북 하나만 있으면 전 세계 어디든 가서 똑같이 여행할 수 있다!"라고 약속했습니다. 하지만 이 논문은 그 약속이 아직 완벽하지 않다고 지적합니다.

---

🔍 연구자가 발견한 3 가지 문제점

이 논문은 SYCL 이 약속한 세 가지 목표 (이동성, 생산성, 성능) 를 시험해 보았는데, 다음과 같은 문제들이 발견되었습니다.

1. 이동성 (Portability): "가이드북은 통하지만, 현지 사정은 달라요"

• 상황: 가이드북 (코드) 을 그대로 들고 일본 (GPU) 에 갔는데, 현지인 (컴파일러) 이 "이 부분은 우리 식으로 고쳐야 해요"라고 합니다.
• 문제: SYCL 은 코드를 수정하지 않고도 여러 기기에서 실행되게 해줍니다. 하지만 실제로는 기기마다 동작 방식이 조금씩 달라서, 가끔은 코드를 살짝 고치거나 테스트를 다시 해야 할 때가 많습니다.
• 비유: "이 가이드북은 전 세계 어디서나 쓰일 수 있다고 했지만, 일본에서는 '전철'을 '지하철'로 바꿔서 읽어야 하고, 독일에서는 '기차'를 '고속철'로 바꿔서 읽어야 해요."

2. 생산성 (Productivity): "선택의 폭이 너무 넓어서 오히려 골치 아파요"

• 상황: 여행자가 물건을 챙길 때 두 가지 방법이 있습니다.
  1. USM (유니피드 공유 메모리): "가방에 다 넣으면 가이드가 알아서 챙겨줘." (자동화)
  2. 버퍼 (Buffer): "이건 내가 직접 챙겨야 해. 언제 가져오고 언제 가져갈지 정해야 해." (수동)
• 문제: SYCL 은 두 가지 방법을 모두 제공합니다. 하지만 어떤 것을 써야 더 빠를지 미리 알 수 없습니다. 개발자는 "어떤 방법을 쓸까?" 고민하다가 시간을 낭비하거나, 실수로 느린 방법을 골라버립니다.
• 비유: "가이드가 '자동으로 챙겨줄게'라고 하지만, 실제로는 '직접 챙기는 게 더 빠를 수도 있어'라고 말합니다. 그래서 여행자는 매번 '어떤 걸 선택해야 할지' 고민하느라 지칩니다."

3. 성능 (Performance): "같은 가이드북인데 결과가 천차만별"

• 상황: 같은 여행 코스를 돌았는데, **가이드북의 종류 (NDRange vs 계층적 커널)**에 따라 여행 시간이 1 시간 걸리기도 하고, 40 시간 걸리기도 했습니다.
• 문제: 논문은 실험을 통해 버퍼 방식이 USM 방식보다 훨씬 빠르고 안정적임을 증명했습니다. 특히 CPU 에서는 USM 이 너무 느려서 (최대 60 배 이상) 쓸모가 없었습니다.
• 비유: "미국에서는 '차'를 타고 1 시간 걸리는데, 일본에서는 같은 '가이드'를 보고 '전철'을 탔더니 40 시간 걸리는 기이한 일이 발생했습니다. 가이드북이 똑같은데 결과가 이렇게 다르니 믿을 수가 없습니다."

---

📊 연구의 주요 결론 (한 줄 요약)

"SYCL 은 '하나의 코드로 모든 기기'를 실행하게 해주는 훌륭한 시도지만, 아직 '완벽한 만능 키'는 아닙니다."

• 기능은 되지만: 코드가 여러 기기에서 실행은 됩니다.
• 성능은 불안정: 어떤 방법을 쓰느냐에 따라 속도가 10 배, 40 배까지 차이가 납니다.
• 개발자는 여전히 고생: 개발자는 SYCL 이 자동으로 해줄 거라고 기대하지만, 실제로는 "어떤 하드웨어에 어떤 방법을 써야 가장 빠를지" 직접 실험하고 튜닝해야 합니다.

🚀 앞으로의 전망

논문은 SYCL 이 완전히 실패한 것은 아니라고 말합니다. 다만, **Khronos 그룹 (SYCL 을 만든 단체)**이 다음과 같은 변화를 가져와야 한다고 제안합니다.

1. 규칙을 명확히 하기: "어떤 기기에서는 이렇게 동작한다"는 것을 명확히 정해야 합니다.
2. 자동화 강화: 개발자가 "어떤 걸 쓸지" 고민하지 않아도, 컴파일러가 알아서 가장 빠른 방법을 골라주게 해야 합니다.
3. 도구 개선: 개발자가 실수하지 않도록 도와주는 더 좋은 도구들이 필요합니다.

💡 결론

SYCL 은 **"미래의 완벽한 여행 가이드"**가 될 잠재력이 충분합니다. 하지만 지금은 "가이드북을 들고 가도, 현지 사정에 따라 여행자가 직접 길을 찾아야 하는" 과도기 상태입니다. 개발자들은 SYCL 을 쓸 때 "편리함"을 기대하기보다, "성능을 위해 직접 세팅해야 한다"는 점을 염두에 두어야 합니다.

기술 요약

논문 요약: 이기종 시스템을 위한 통합 프로그래밍 모델로서의 SYCL 평가

1. 문제 정의 (Problem)

고성능 컴퓨팅 (HPC) 애플리케이션은 CPU, GPU, FPGA 등 다양한 하드웨어 아키텍처가 혼합된 이기종 환경에서 실행되는 경우가 늘어나고 있습니다. 이러한 환경에서 소프트웨어의 이식성 (Portability) 과 개발 생산성 (Productivity) 을 유지하는 것은 큰 도전 과제입니다.
SYCL 은 단일 소스 (Single-source) 로 이기종 하드웨어를 프로그래밍할 수 있게 해주는 표준으로 부상했으나, 개발자들은 SYCL 이 실제로 이식성, 생산성, 성능이라는 세 가지 핵심 목표를 모두 달성하는지, 특히 "단일 소스로 모든 플랫폼에서 일관된 성능을 보장하는가"에 대해 명확하지 않은 상태입니다.
본 논문은 SYCL 이 이러한 목표를 달성하지 못하고 있는 **격차 (Gap)**를 규명하고, 현재 SYCL 구현체들의 한계와 불일치를 분석하는 것을 목적으로 합니다.

2. 연구 방법론 (Methodology)

저자는 SYCL 을 평가하기 위해 **"싱귤래리티 (Singularity)"**라는 개념을 정의하고 이를 기준으로 분석을 진행했습니다.

• 싱귤래리티 정의: 소스 코드 변경 없이 다양한 하드웨어 아키텍처, 컴파일러, 백엔드에서 이식성, 생산성, 성능을 모두 만족하는 프로그래밍 모델의 능력.
• 평가 대상: SYCL 의 핵심 추상화인 **데이터 관리 모델 (USM vs. Buffer-Accessor)**과 **병렬성 모델 (NDRange vs. Hierarchical Kernels)**의 4 가지 조합.
• 벤치마크 환경:
  • 하드웨어: Intel Max 1100 GPU, NVIDIA A100 GPU, AMD MI250 GPU, Intel Xeon CPU.
  • 소프트웨어: Intel oneAPI DPC++, Codeplay ComputeCpp, AdaptiveCpp (hipSYCL 포함).
  • 작업 부하 (Workloads): 벡터 덧셈, 행렬 곱셈, 축소 (Reduction) 연산 등.
• 분석 방식: 자체 벤치마크 수행 및 최근 관련 연구 (HeCBench, PLSSVM 등) 결과 종합.

3. 주요 기여 (Key Contributions)

1. 개발자 중심 요구사항 정의: 이식성, 생산성, 성능을 기준으로 SYCL 의 "싱귤래리티" 달성 여부를 평가하는 기준을 제시.
2. 메모리 관리 전략 비교: USM(통합 공유 메모리) 과 Buffer-Accessor 모델의 성능 및 이식성 영향에 대한 심층 분석.
3. 병렬성 모델 비교: NDRange(평면적) 와 Hierarchical(계층적) 커널 모델의 성능 일관성 평가.
4. 다양한 플랫폼 벤치마크: Intel, NVIDIA, AMD 등 다양한 하드웨어와 DPC++, hipSYCL 등 여러 컴파일러/구현체에서의 성능 데이터를 제공.
5. 현실적 한계 규명: SYCL 이 "한 번 작성하면 어디서든 실행"이라는 목표를 달성하지 못하며, 개발자가 여전히 아키텍처별 최적화가 필요함을 증명.

4. 주요 결과 (Key Results)

• 메모리 관리 모델 (USM vs. Buffer):

  • Buffer-Accessor 모델이 USM 모델보다 일관되게 우수한 성능을 보였습니다.
  • 특히 CPU 환경에서 Buffer 모델은 USM(암시적 전송) 보다 최대 66.9 배까지 빨랐습니다.
  • USM 의 암시적 데이터 전송 (Implicit transfer) 은 오버헤드가 크고 성능이 불안정하여, 명시적 전송 (Explicit) 이나 Buffer 모델을 사용해야만 경쟁력 있는 성능을 얻을 수 있었습니다.
  • 결론: 메모리 모델 선택에 따라 성능이 크게 달라지므로, 모델 간 교환 가능성 (Interchangeability) 이 보장되지 않습니다.

• 병렬성 모델 (NDRange vs. Hierarchical):

  • GPU 환경: NDRange 커널이 Hierarchical 커널보다 훨씬 우수했습니다 (행렬 곱셈에서 최대 42.7 배 차이).
  • CPU 환경: Hierarchical 커널이 NDRange 보다 약간 우세하거나 비슷했으나, 구현체 (DPC++ vs hipSYCL) 에 따라 성능 편차가 극심했습니다.
  • 컴파일러/구현체 의존성: 동일한 코드라도 사용하는 컴파일러 (DPC++ vs hipSYCL) 에 따라 성능이 **수십 배에서 수백 배 (Orders of magnitude)**까지 차이 나는 경우가 발생했습니다.

• 싱귤래리티 달성 여부:

  • 이식성 (Portability): 기능적 이식성은 어느 정도 달성되었으나, 시맨틱 불일치 (데이터 동기화, 메모리 수명 등) 로 인해 플랫폼별 수정이 필요할 수 있습니다.
  • 생산성 (Productivity): 개발자가 성능을 위해 추상화 모델 (USM vs Buffer, NDRange vs Hierarchical) 을 선택하고 벤치마크를 수행해야 하므로 생산성이 저하됩니다.
  • 성능 (Performance): 추상화 모델과 플랫폼에 따라 성능 편차가 극심하여 (최대 40 배 이상), 성능 이식성은 달성되지 않았습니다.

5. 의의 및 결론 (Significance & Conclusion)

• SYCL 의 현재 상태: SYCL 은 이기종 컴퓨팅을 위한 통합 프로그래밍 모델로서의 잠재력을 가지고 있으나, "완전한 Singularity"에는 도달하지 못했습니다. 개발자는 여전히 타겟 하드웨어와 컴파일러에 맞춰 메모리 모델과 커널 타입을 선택하고 최적화해야 합니다.
• 기술적 시사점:
  • Buffer-Accessor와 NDRange 조합이 현재 가장 안정적이고 성능이 좋은 선택지로 보입니다.
  • USM은 사용 편의성은 높으나, 암시적 전송 시 성능 저하가 심각하여 생산성만으로는 부족합니다.
  • Hierarchical 커널은 CPU 에 적합할 수 있으나, GPU 에서는 비효율적이며 구현체 간 성능 편차가 큽니다.
• 미래 전망:
  • Khronos 그룹은 SYCL 2020 명세서 개정 10 에서 Hierarchical 커널을 **폐기 (Deprecate)**하기로 발표했습니다.
  • 진정한 Singularity 를 달성하기 위해서는 추상화의 시맨틱 보장 강화, 성능을 고려한 추상화 개발, 통합된 도구 (Tooling) 지원, 그리고 컴파일러가 아키텍처에 맞는 최적의 추상화를 자동으로 선택하는 기술이 필요합니다.

요약하자면, 이 논문은 SYCL 이 "한 번 작성하면 어디서든 실행"이라는 이상을 실현하기 위해서는 아직 해결해야 할 성능 불일치와 복잡성 문제가 많음을 데이터 기반으로 증명했습니다.