Machine Translated by Google
새로운 패러다임 벤치마킹: 실제 메모리 내 처리 아키텍처에 대한 실험적 분석 Juan
Gómez‑Luna1 Izzat El Hajj2 Ivan Fernandez1,3
Christina Giannoula1,4 Geraldo F. Oliveira1 Onur Mutlu1
1ETH 취리히 2베이루트 아메리칸 대학교 3말라가 대학교 4아테네 국립기술대학교
추상적인
신경망, 데이터베이스, 그래프 처리 등 현대의 많은 워크로드는 기본적으로 메모리
에 바인딩되어 있습니다. 이러한 워크로드의 경우 메인 메모리와 CPU 코어 간의 데
이터 이동으로 인해 대기 시간과 에너지 측면에서 상당한 오버헤드가 발생합니다 .
주된 이유는 이러한 통신이 대기 시간이 길고 대역폭이 제한된 좁은 버스를 통해 이
루어지며, 메모리 바인딩된 워크로드에서 낮은 데이터 재사용률이 메인 메모리 액세
스 비용을 상각하기에 충분하지 않기 때문입니다. 이러한 데이터 이동 병목 현상을
근본적으로 해결하려면 메모리 시스템이 처리 기능을 통합하여 컴퓨팅에서 적극적
인 역할을 맡는 패러다임이 필요합니다 . 이 패러다임을 PIM( Processing‑In‑
Memory)이라고 합니다 .
최근 연구에서는 처리 요소를 쉽게 배치할 수 있는 로직 레이어와 메모리를 통합
하는 새로운 3D 스택 메모리 기술의 출현에 힘입어 다양한 형태의 PIM 아키텍처
를 탐구합니다 . 과거 연구에서는 시뮬레이션을 통해 또는 기껏해야 단순화된 하드
웨어 프로토타입을 사용하여 이러한 아키텍처를 평가했습니다.
이와 대조적으로 UPMEM 회사는 공개적으로 사용 가능한 최초의 실제 PIM 아키
Ai2.Xs0r일
7v41830.501]2R:v2 년
월
ca
2[
5
4
텍처를 설계하고 제조했습니다. UP‑ MEM PIM 아키텍처는 기존 DRAM 메모리
어레이를 동일한 칩에 통합된 DPU(DRAM 처리 장치)라고 하는 범용 순차 코어와
결합합니다.
이 백서는 공개적으로 사용 가능한 최초의 실제 PIM 아키텍처에 대한 최초의 포
괄적인 분석을 제공합니다. 우리는 두 가지 중요한 기여를 합니다. 먼저 마이크로벤
치마크를 사용하여 UPMEM 기반 PIM 시스템의 실험적 특성화를 수행하여 컴퓨
팅 처리량 및 메모리 대역폭과 같은 다양한 아키텍처 제한을 평가하고 새로운 통찰
력을 얻습니다. 둘째, 다양한 애플리케이션 도메인(예: 조밀/희소 선형 대수, 데이터
베이스, 데이터 분석, 그래프 처리, 신경망 , 생물정보학, 이미지 처리)의 16개 워크
로드로 구성된 벤치마크 제품군인 PrIM (Processing‑In‑Memory 벤치마크 )을
제시합니다. 우리는 이를 메모리 바인딩으로 식별합니다. 우리는 UPMEM PIM 아
키텍처에서 PrIM 벤치마크의 성능 및 확장 특성을 평가 하고 성능 및 에너지 소비
를 최신 CPU 및 GPU와 비교합니다. 640 및 2,556 DPU를 갖춘 두 개의 실제
UPMEM 기반 PIM 시스템에 대해 수행된 광범위한 평가 는 PIM 시스템에 대한 다
양한 워크로드 의 적합성에 대한 새로운 통찰력 , 소프트웨어 설계자를 위한 프로그
래밍 권장 사항, 미래 PIM의 하드웨어 및 아키텍처 설계자를 위한 제안 및 힌트를
제공합니다. 시스템.
키워드
메모리 내 처리, 근접 데이터 처리, 메모리 시스템, 데이터 이동 병목 현상, DRAM,
벤치마킹, 실제 시스템 특성화, 워크로드 특성화
1. 소개
최신 컴퓨팅 시스템에서는 최신 데이터 집약적 워크로드의 실행 시간과 에너지 소비
의 상당 부분이 메모리와 프로세서 코어 간에 데이터를 이동하는 데 사용됩니다. 이
러한 데이터 이동 병목 현상 [1‑7] 은 수십 년 동안 프로세서 코어의 성능이 메모리
성능보다 빠른 속도 로 증가해 왔다는 사실에서 비롯됩니다 . 지연 시간과 에너지
측면에서 산술 연산과 메모리 액세스 간의 격차는 계속 커지고 있으며 메모리 액세
스 비용은 점점 더 비싸지고 있습니다. 그 결과, 최근 실험 연구에서는 전체 시스템
의 62% [8] (2018년 보고), 40% [9] (2014년 보고), 35% [10] (2013년 보고)
를 차지하는 것으로 보고하고 있다. 다양한 소비자, 과학, 모바일 애플리케이션에
각각 사용되는 에너지입니다.
데이터 이동 병목 현상을 완화하는 유망한 방법 중 하나 는 메모리 칩에 처리
기능을 장착하는 PIM(Processing‑in‑Memory)입니다 [2]. 이 패러다임은 50
년 이상 동안 탐구되어 왔지만 [1‑4, 8, 11‑131], 메모리 기술의 한계로 인해 상
용 하드웨어가 성공적으로 구현되지 못했습니다. 최근에는 DRAM 스케일링의 어려
움(즉, 신뢰성, 대기 시간 및 에너지 소비를 유지하면서 밀도 및 성능을 높이는 데
어려움을 겪음 ) [132‑166] 으로 인해 3D 스택 메모리 [63, 167‑172] 와 같은
혁신이 이루어졌습니다 . 처리 기능을 통합하면서 메모리 하위 시스템을 재설계할
수 있는 새로운 기회를 제공하는 비 휘발성 메모리 [146, 173–183] . 3D 스택 메
모리는 처리 요소를 내장할 수 있는 로직 레이어와 DRAM 레이어를 통합합니다.
여러 연구에서는 범용 코어 [8, 56, 63–67, 128, 184] 와 같은 논리 계층 에서 다
양한 유형의 처리 구성 요소를 구현하기 위해 PNM(Processing‑Near‑
Memory) 이라고 하는 이 접근 방식을 탐구합니다. 응용별 가속기 [57–61, 69,
79, 81, 82 , 88, 89, 101, 104, 105, 107, 108, 124–127, 129–131, 185,
186], 단순 기능 단위 [62, 84, 120, 122, 123, 187], GPU 코어 [78, 80, 85,
87] 또는 재구성 가능한 논리 [68, 73, 75, 121]. 그러나 3D 스택 메모리는 높은
비용과 제한된 용량으로 인해 어려움을 겪고 있으며 로직 레이어에는 하드웨어 영
역 및 열 방출 제약이 있어 내장된 처리 구성 요소의 기능이 제한됩니다. 반면, 메
모리를 이용한 처리(PUM)는 SRAM [21‑24 ], DRAM [25‑40, 99, 100, 119,
188‑191] 또는 비휘발성 메모리 셀의 아날로그 작동 속성을 활용합니다. 메모리
[41–55, 70, 103, 114, 118, 192–196] 특정 유형의 작업을 효율적으로 수행합
니다. 그러나 메모리를 사용한 처리는 간단한 비트 연산(예: 다수, AND, OR)으로
제한되며 [21, 25, 26, 188, 191] 더 복잡한 연산을 수행 하려면 높은 영역 오버
헤드가 필요합니다 [35, 36 , 99] 또는 비트 직렬 계산을 가능하게 하기 위해 데이
터 구성, 조작 및 처리 메커니즘에 대한 상당한 변경이 필요하지만 여전히 제한 사
항이 있습니다.
Machine Translated by Google
특정 작업에 대해 [29, 37, 40].1 더욱이 메모리를 사용한 처리 접근 방식은 일반적으로 주
로 정규 계산에 효율적입니다 . 왜냐하면 자연스럽게 많은 수의 메모리 셀(예: 여러 개의 전
체 행에 걸쳐 있는 전체 행) 에서 작동하기 때문입니다. 하위 배열 [25–28, 37, 188–191 ,
197]) 을 동시에 생성합니다. 이러한 이유로 3D 스택 메모리 또는 메모리를 사용한 처리를
기반으로 하는 완전한 PIM 시스템은 아직 실제 하드웨어에서 상용화되지 않았습니다.
UPMEM PIM 아키텍처 [198, 199]는 실제 하드웨어에서 상용화된 최초의 PIM 시스
템입니다 . 앞서 언급한 문제를 방지하려면
제한 사항이 있기 때문에 기존 2D DRAM 어레이를 사용하고 이를 DPU(DRAM 처리 장
치)라고 하는 범용 처리 코어와 동일한 칩에 결합합니다. 동일한 칩에 메모리와 처리 구성
요소를 결합하면 심각한 설계 문제가 발생합니다. 예를 들어, DRAM 디자인은 단지 3개의
금속 레이어[200, 201]만을 사용하는 반면 , 기존 프로세서 디자인은 일반적 으로 10개 이
상의 금속 레이어를 사용합니다 [199, 202‑204]. 이러한 문제로 인해 빠른 논리 트랜지스
터를 제작할 수 없는 반면, UPMEM은 수백 메가헤르츠에서 실행되도록 상대적으로 깊게
파이프라인되고 세분화 된 멀티스레드 [205‑209] 인 DPU 코어를 통해 이러한 문제를 극
복합니다 . UPMEM PIM 아키텍처는 다른 PIM 제안과 관련하여 몇 가지 주요 이점을 제
공합니다. 첫째, 최신 3D 스택 메모리 기술의 단점을 피하면서 성숙한 2D DRAM 설계 및
제조 공정을 사용합니다 . 둘째, 범용 DPU는 단순한 최신 범용 프로세서와 유사하게 다양
한 계산 및 데이터 유형을 지원합니다 . 셋째, 이 아키텍처는 DPU의 스레드가 서로 독립적
으로 실행될 수 있기 때문에 불규칙한 계산에 적합합니다 (즉, SIMD2에서와 같이 잠금 단
계 실행에 의해 바인딩되지 않음 ). 넷째, UPMEM은 일반적으로 사용되는 C 언어로 DPU
프로그램을 작성할 수 있는 완전한 소프트웨어 스택을 제공합니다 [213].
최초의 공개 PIM 아키텍처인 UPMEM PIM 아키텍처와 다양한 워크로드
에 대한 적합성을 엄격하게 이해 하면 이 아키텍처는 물론 미래의 PIM 시스템
에 대한 프로그래머, 사용자, 설계자에게 귀중한 통찰력을 제공할 수 있습니
다 . 이를 위해 우리의 작업은 공개적으로 사용 가능한 최초의 실제 PIM 아키
텍처에 대한 최초의 포괄적인 실험적 특성화 및 분석을 제공합니다. 실험적 연
구와 분석을 가능하게 하기 위해 우리는 공개적이고 자유롭게 사용할 수 있는
새로운 마이크로벤치마크와 새로운 벤치마크 제품군을 개발합니다 [214].
우리는 UPMEM 기반 PIM 시스템의 한계를 평가, 특성화 및 이해하여 새로운
통찰력을 얻기 위해 일련의 마이크로벤치마크를 개발합니다. 먼저 다양한 산술 연
산 및 데이터 유형에 대한 DPU 의 컴퓨팅 처리량을 얻습니다 . 둘째, DPU가 로드/
저장 명령을 사용하여 직접 액세스할 수 있는 두 가지 메모리 공간, 즉 (1) Main
RAM(MRAM)이라고 하는 DRAM 뱅크와 (2) Working이라고 하는 SRAM 기반
스크래치 패드 메모리 의 대역폭을 측정 합니다. 램(WRAM). 우리는 두 유형의 메
모리 모두에서 지속되는 대역폭을 측정하기 위해 스트리밍 (즉, 단위 스트라이드),
스트라이드 및 무작위 메모리 액세스 패턴을 사용합니다. 셋째, 표준메인간 지속대
역폭을 측정한다.
1비트 직렬 계산을 수행하는 PUM 접근 방식 [29, 37, 40] 은 데이터 요소를 수직으로 레이아웃해야 합니다 (즉, 동
일한 비트라인에 있는 요소의 모든 비트). 이는 (1) 특정 데이터 조작 작업(예: 셔플링)을 허용 하지 않습니다. 배열의
데이터 요소) 및 (2)는 데이터 형식을 변경해야 할 때(즉, 비트 직렬 계산을 수행하기 전에) 비트 전치의 오버헤드를 지
불해야 합니다.
2
SIMD(Single Instruction Multiple Data) [210–212] 는 여러 처리 요소가 여러 데이터 요소에 대
해 동일한 작업을 동시에 실행하는 실행 패러다임을 나타냅니다.
2
다양한 유형과 크기의 전송을 위한 메모리와 MRAM 뱅크는 DPU와 호스트
CPU 및 기타 DPU 의 통신에 중요합니다 .
실제 PIM 아키텍처를 위한 최초의 벤치마크 제품군인 PrIM (Processing‑In‑
Memory 벤치마크)을 소개합니다 . PrIM에는 16개의 작업이 포함되어 있습니다.
다양한 애플리케이션 도메인(예: 조밀/희소 선형 대수학, 데이터베이스, 데이
터 분석, 그래프 처리, 신경망, 생물정보학, 이미지 처리)의 로드(예: 기존 CPU
의 루프라인 모델을 사용하여 메모리 바인딩된 것으로 식별) ]. 우리는 2,556
개의 DPU가 있는 시스템에서 16개의 벤치마크를 사용하여 강력한 스케일링
3 및 약한 스케일링4 실험을 수행 하고 성능 및 에너지 소비를 최신 CPU 및
GPU와 비교합니다. 우리의 광범위한 평가는 PIM 시스템에 대한 다양한 워크
로드의 적합성에 대한 새로운 통찰력, 소프트웨어 설계자를 위한 프로그래밍
권장 사항, 미래 PIM 시스템의 하드웨어 및 아키텍처 설계자를 위한 제안 및
힌트를 제공합니다 . 우리의 모든 마이크로벤치마크와 PrIM 벤치마크는 공개
적 으로 무료로 제공되어 [214] 실제 PIM 아키텍처 에 대한 프로그래밍 샘플
역할을 하고 , 현재와 미래의 PIM 시스템을 평가 및 비교하며, PIM 아키텍처,
프로그래밍 및 소프트웨어 연구를 더욱 발전시키는 데 도움이 됩니다.5
이 작업의 주요 기여는 다음과 같습니다.
• 우리는 공개적으로 사용 가능한 최초의 실제 PIM 아키텍처에 대한 최초의 포괄적인 특성
화 및 분석을 수행합니다. 우리는 새로운 아키텍처의 잠재력, 한계 및 병목 현상을 분석
합니다.
우리는 (1) 다양한 메모리 액세스 패턴에 대한 DPU 메모리 계층의 다양한
수준에서 메모리 대역폭 , (2) 다양한 데이터 유형에 대한 다양한 산술 연산
의 DPU 컴퓨팅 처리량 , (3) 다양한 계산에 대한 강하고 약한 스케일링 특
성을 분석합니다. 패턴. 우리는 (1) UPMEM PIM 아키텍처가 기본적으로 컴
퓨팅 바운드라는 점을 발견했습니다. 왜냐하면 정수 추가보다 더 복잡한 작
업을 수행하는 워크로드는 잠재적으로 메모리 대역폭을 포화시키기 전에 명
령 파이프라인을 완전히 활용하고 (2) DPU 간 통신이 필요한 워크로드를
완전히 활용하기 때문입니다. DPU 간에 직접적인 통신 채널이 없기 때문
에 확장성이 좋지 않습니다. 따라서 모든 DPU 간 통신은 호스트 CPU, 즉
좁은 메모리 버스를 통해 이루어집니다 . • 우리는 기존 프로세서 중심 시스
템에 메모리 바인딩된 16개의 실제 작업 부하로 구성된 실제 PIM 아키텍처
에 대한 최초의 벤치마크 제품군인 PrIM을 공개하고 오픈 소스로 제공합니
다.
워크로드는 메모리 액세스 패턴, 작업 및 데이터 유형, 통신 패턴에서 이질
성을 나타내는 다양한 특성을 가지고 있습니다. PrIM 벤치마크 제품군은
UPMEM PIM 아키텍처를 평가하기 위한 공통 워크로드 세트를 제공하며
프로그래밍, 아키텍처 및 시스템 연구자 모두가 미래 PIM 하드웨어 및 소프
트웨어의 여러 측면을 개선하는 데 유용할 수 있습니다 .5 • 성능과 소프트
웨어를 비교합니다. 2,556개의 DPU와 640개의 DPU를 갖춘 2개의
UPMEM 기반 PIM 시스템과 현대의 기존 프로세서 중
심 시스템에 대한 PrIM 벤치마크의 에너지 소비량 ,
삼
강력한 스케일링은 특정 문제를 해결하는 프로그램의 실행 시간이 고정된 문제 크기에 대한 프로세서 수에 따라 어
떻게 달라지는지를 나타냅니다[216, 217].
4약한 스케일링은 특정 문제를 해결하는 프로그램의 실행 시간이 프로세서당 고정된 문제 크기에 대한 프로세서 수에
따라 어떻게 달라지는지를 나타냅니다 [216, 218].
5우리는 독자들에게 최첨단 과제에 관한 최근 개요 논문 [2] 을 소개합니다.
PIM 연구에서.
Machine Translated by Google
즉, CPU와 GPU입니다. 우리의 분석은 몇 가지 새롭고 흥미로운 결과를 보여
줍니다. 우리는 세 가지 주요 결과를 강조합니다. 첫째, 두 UPMEM 기반 PIM
시스템 모두 PrIM 벤치마크 중 13개에서 최신 CPU( 평균 각각 93.0배 및 27.9
배 )보다 성능이 뛰어나며 집중적인 DPU 간 동기화 또는 부동 소수점 연산이
필요하지 않습니다.6 섹션 5.2에서는 PIM 시스템을 최신 CPU 및 GPU와 비교
한 자세한 분석을 제공합니다.
둘째, 2,556‑DPU PIM 시스템은 (1) 스트리밍 메모리 액세스, (2) DPU 간
동기화가 거의 또는 전혀 없음, (3) 거의 없는 10 PrIM 벤치마크에서 최신
GPU보다 빠릅니다 (평균 2.54배 ). 또는 복잡한 산술 연산(예: 정수 곱셈/
나누기, 부동 소수점 연산) 을 사용하지 않습니다 .7 셋째, PIM, CPU 및
GPU 시스템의 에너지 소비 비교는 성능 비교와 동일한 추세를 따릅니다.
CPU 및 GPU보다 성능이 크게 뛰어난 워크로드의 경우 CPU 및 CPU에 비
해 에너지가 크게 절약됩니다.
우리는 최초의 상용 PIM 시스템을 아키텍처, 소프트웨어 및 제조 측면에서
수십 년 동안 고도로 최적화된 CPU 및 GPU 시스템 과 비교하고 있습니다.
그럼에도 불구하고 우리는 대부분의 PrIM 벤치마크(섹션 5.2)에서 CPU 및
GPU에 비해 PIM의 상당한 이점을 확인했습니다. 우리는 PIM 시스템의 아
키텍처, 소프트웨어 및 제조가 계속해서 개선될 것이라고 믿습니다(예: 섹션
6에서 향후 개선을 위한 최적화 및 영역 제안 ). 따라서 CPU 및 GPU 시스템
에 대한 보다 공정한 비교가 가능하며 향후 PIM 시스템에 대한 더 높은 이점
을 밝힐 수 있습니다.
2 UPMEM PIM 아키텍처
UPMEM PIM 지원 시스템의 구성(섹션 2.1), DPU 코어 아키텍처(섹션 2.2) 및
DPU 프로그래밍의 중요한 측면(섹션 2.3)에 대해 설명합니다.
2.1 시스템 구성 그림 1(왼쪽)은 (1) 호스
트 CPU(예: x86 [219], ARM64 [220] 또는 64비트 RISC‑V [221] 멀티 코어
시스템을 갖춘 UPMEM 기반 PIM 시스템을 보여줍니다. ), (2) 표준 메인 메모
리(DRAM 메모리 모듈 [222‑225]), (3) PIM 지원 메모리(UPMEM 모듈 )
[198, 199]. PIM 지원 메모리는 하나 이상의 메모리 채널에 상주할 수 있습니
다. UPMEM 모듈은 여러 PIM 칩이 포함된 표준 DDR4‑2400 DIMM(모듈)
[226] 입니다. 그림 2는 두 개의 UPMEM 모듈을 보여줍니다. UPMEM 모듈의
모든 DPU는 호스트 CPU에 대한 병렬 보조 프로세서로 함께 작동합니다.
각 UPMEM PIM 칩(그림 1(오른쪽)) 내부에는 8개의 DPU가 있습니다.
각 DPU는 (1) 메인 RAM(MRAM) 이라고 하는 64MB DRAM 뱅크, (2)
IRAM(명령어 RAM) 이라고 하는 24KB 명령어 메모리 및 (3) 64KB DRAM 뱅크
에 독점적으로 액세스할 수 있습니다. WRAM(Working RAM)이라고 불리는 스
크래치패드 메모리 . MRAM은 입력 데이터를 복사하기 위해 호스트 CPU(그림
1(왼쪽))에서 액세스할 수 있습니다(메인 메모리에서
6다른 세 가지 PrIM 벤치마크 중 두 가지인 BFS(Breadth‑First Search)와
NW(Needleman‑Wunsch)는 호스트 CPU를 통한 DPU 간 동기화의 막대한 오버헤드를 지불합니다.
세 번째 방법인 SpMV(Sparse Matrix‑Vector Multiply)는 부동 소수점 곱셈과 덧셈을 집중적으로
사용합니다.
7또한 640‑DPU PIM 시스템을 평가한 결과 대부분의 PrIM 벤치마크에서 GPU보다
느리지만 두 시스템(640‑DPU PIM 및 GPU) 간의 성능 격차는 그렇지 않은 10 PrIM
벤치마크에서 상당히 작았습니다. (1) DPU 간 통신이 많거나 (2) 곱셈 연산을 집중적
으로 사용해야 합니다 .
640‑DPU PIM 시스템은 GPU에 적합하지 않은 두 가지 벤치마크에서 GPU보다 빠릅니
다. 섹션 5.2에서는 비교에 대한 자세한 분석을 제공합니다.
삼
MRAM) 결과 검색(MRAM에서 메인 메모리로) .
이러한 CPU‑DPU 및 DPU‑CPU 데이터 전송은 모든 MRAM 뱅크에서/으로 전송
되는 버퍼의 크기가 동일한 경우 병렬로(즉, 여러 MRAM 뱅크에서 동시에) 수행될
수 있습니다 .
그렇지 않으면 데이터 전송이 순차적으로 발생합니다. 즉, 다른 MRAM 뱅크와의
전송은 MRAM과의 전송 이후에 시작됩니다.
은행 완료). DPU 간의 직접 통신은 지원되지 않습니다 . 모든 DPU 간 통신은
DPU에서 CPU로 결과를 검색하고 CPU에서 DPU로 데이터를 복사하는 방식으
로 호스트 CPU를 통해 이루어집니다. 현재 UPMEM 기반 PIM 시스템에서는 동일
한 MRAM 뱅크에 대한 호스트 CPU와 DPU의 동시 액세스가 불가능합니다.
직렬 전송을 위한 프로그래밍 인터페이스 [213] 는 특정 MRAM 뱅크로
(dpu_copy_to) 및 특정 MRAM 뱅크 에서 (dpu_copy_from) 버퍼를 복사하
는 기능을 제공합니다 . 병렬 전송을 위한 프로그래밍 인터페이스 [213] 는 버퍼를
특정 MRAM 뱅크 (dpu_prepare_xfer) 에 할당한 다음 실제 CPU‑DPU 또는
DPU‑CPU 전송을 시작하여 병렬 로 실행하는 기능 (dpu_push_xfer)을 제공
합니다. 병렬 전송을 위해서는 모든 MRAM 뱅크와의 전송 크기가 동일해야 합니
다. 모든 MRAM 뱅크에 복사 할 버퍼가 동일하면 브로드캐스트 CPU‑DPU 메모
리 전송(dpu_broadcast_to)을 실행할 수 있습니다.
주 메모리와 PIM 지원 메모리에는 서로 다른 데이터 레이아웃이 필요합니다. 메
인 메모리는 연속적인 8비트 워드를 연속적인 DRAM 칩에 매핑하는 기존 수평
DRAM 매핑 [199, 228] 을 사용하는 반면, PIM 지원 메모리는 동일한 MRAM 뱅
크(하나의 PIM 칩 에서)에 매핑된 전체 64비트 워드가 필요합니다. ) [199]. PIM
지원 메모리에 이러한 특수 데이터 레이아웃이 있는 이유는 각 DPU가 단일 MRAM
뱅크에만 액세스할 수 있지만 최대 64비트의 데이터 유형에서 작동할 수 있기 때문
입니다. UPMEM SDK에는 메인 메모리와 MRAM 뱅크 간에 데이터를 전송할 때
필요한 데이터 셔플링을 수행하는 전치 라이브러리 [199] 가 포함되어 있습니다 .
이러한 데이터 레이아웃 변환은 프로그래머에게 투명합니다 . 직렬/ 병렬/브로드캐
스트 CPU‑DPU 및 직렬/병렬 DPU‑CPU 전송을 위해 UPMEM SDK에서 제공
하는 기능은 내부적으로 전치 라이브러리를 호출하며, 라이브러리는 최종적으로 필
요에 따라 데이터 레이아웃 변환을 수행합니다.
호스트 CPU는 DPU 기능이나 커널을 실행하기 위해 원하는 수의 DPU, 즉
DPU 세트를 할당할 수 있습니다. 그런 다음 호스트 CPU는 DPU 커널을 동기식
또는 비동기식으로 시작합니다 [213].
동기 실행은 DPU 세트가 커널 실행을 완료할 때까지 호스트 CPU
스레드를 일시 중지합니다 . 비동기 실행은 즉시 호스트 CPU 스레
드에 제어권을 반환하며, 나중에 완료 상태를 확인할 수 있습니다
[213].8
현재 UPMEM 기반 PIM 시스템 구성 [227] 에서 UPMEM DIMM의 최
대 수는 20개입니다. UPMEM 기반 PIM
20개의 UPMEM 모듈이 있는 시스템은 최대 2,560개의 DPU를 포함할 수 있으
며 이는 160GB의 PIM 지원 메모리에 해당합니다.
표 1은 두 가지 실제 UPMEM 기반 PIM 시스템을 보여줍니다.
우리는 이 작업에 사용합니다.
우리는 2,556개의 DPU와 총 159.75GB MRAM을 포함하는 실제
UPMEM 기반 PIM 시스템을 사용합니다 . DPU는 다음과 같이 구성됩니다.
8
이 작업에서는 벤치마크(섹션 4))가 DPU 커널이 실행되는 동안 컴퓨팅을 위해 호스트 CPU를 요구
하지 않기 때문에 동기 실행만 사용합니다 . 우리는 비동기 실행의 사용을 탐구하는 것이 향후 작업에
서 유망한 주제라고 믿습니다 .
Machine Translated by Google

PIM 칩
메인 메모리
제어/상태 인터페이스 DDR4 인터페이스

음주 음주 음주 음주 음주 음주 음주 음주
칩 칩 칩 칩 칩 칩 칩 칩
4
CPU‑DPU 음주 음주 음주 음주 음주 음주 음주 음주
보내다
칩 칩 칩 칩 칩 칩 칩 칩
가져오기1
xM 6 가져오기2
24KB
주인 가져오기3 IRAM
CPU 읽기OP1 2
5 64MB
DPU‑CPU READOP2 64비트

록
등
일
파
READOP3 음주
체재
PIM PIM PIM PIM PIM PIM PIM PIM 은행

AM엔
진
D
칩 칩 칩 칩 칩 칩 칩 칩 ALU1
ALU2 64KB (MRAM)
PIM PIM PIM PIM PIM PIM PIM PIM ALU3
칩 칩 칩 칩 칩 칩 칩 칩 ALU4
램

로
관
xN 병합1
병합2 삼
PIM 지원 메모리
7 1
x8

그림 1: 호스트 CPU, 표준 메인 메모리, PIM 지원 메모리(왼쪽) 및 내부를 갖춘 UPMEM 기반 PIM 시스템

UPMEM PIM 칩의 구성 요소(오른쪽) [198, 199].

표 1: UPMEM 기반 PIM 시스템.

(a) 메모리 매개변수.
PIM 지원 메모리 DIMM 순위/ DRAM 메모리
체계 DPU/총 코드명 수 DPU 총 수 총
DIMM DIMM DIMM DPU 주파수 메모리 DIMM 메모리

2,556‑DPU 시스템 P21 20 2 128 2,5569 350MHz 159.75GB 4 256GB

640‑DPU 시스템 E19 10 1 64 640 267MHz 40GB 2 64GB

(b) CPU 매개변수.

CPU
체계 CPU CPU 기억. 컨트롤러/소켓 채널/
소켓
프로세서 빈도 기억. 제어 장치

2,556‑DPU 시스템 Intel Xeon Silver 4215 [229] 2.50GHz 2 2 삼

640‑DPU 시스템 인텔 제온 실버 4110 [230] 2.10GHz 1 2 삼

DRAM(호스트 CPU의 주 메모리로 사용)이 하나에 있습니다.

메모리 컨트롤러 중 하나의 채널. 그림 3은 20개의 UPMEM DIMM을 갖
춘 UPMEM 기반 PIM 시스템을 보여줍니다.

PIM 지원
메모리

음주
CPU 1
PIM 지원 메모리

PIM 지원
메모리

음주
CPU 0
그림 2: UPMEM 기반 PIM 모듈(다운로드됨)
[227]에서).
PIM 지원
메모리
20개의 더블 랭크 DIMM(DIMM당 128개의 DPU 포함).9 각 DPU는 실행됩니다.
350MHz에서. 20개의 UPMEM DIMM은 듀얼 x86 소켓에 있습니다.
소켓당 2개의 메모리 컨트롤러. 각 메모리 컨트롤러에는 3개의
메모리 채널 [229]. 각 소켓에는 기존 DIMM 2개가 있습니다.

9실험을 실행하는 시스템에는 결함이 있는 DPU 4개가 있습니다. 그들은 할 수 없어

사용되며 시스템 기능이나 결과의 정확성에는 영향을 미치지 않습니다.
시스템의 전체 컴퓨팅 성능인 2,560 DPU를 사용하지 못하게 됩니다. 그림 3: 2,560개의 DPU를 갖춘 UPMEM 기반 PIM 시스템. 보다
사양은 표 1을 참조하세요.

4
Machine Translated by Google
우리는 또한 640개의 DPU를 갖춘 오래된 실제 시스템을 사용합니다. DPU는
DIMM당 64개의 DPU를 포함하는 10개의 단일 등급 DIMM으로 구성됩니다.
따라서 MRAM의 총 용량은 40GB입니다. 이 시스템의 각 DPU는 267MHz에
서 실행됩니다. 10개의 UPMEM DIMM은 x86 소켓에 있습니다.
2개의 메모리 컨트롤러가 있습니다. 각 메모리 컨트롤러에는 3개의 메모리 채
널이 있습니다 [230]. 기존 DRAM의 DIMM 2개는 메모리 컨트롤러 중 하나
의 채널 에 있습니다 .
2.2 DPU(DRAM 처리 장치) 아키텍처 DPU(그림 1(오른쪽))는 특정 명령
어 세트 아키텍처(ISA) [213] 를 갖춘 다중 스레드 순차 32비트 RISC 코어입
니다 . DPU 에는 24개의 하드웨어 스레드가 있으며 각 스레드에는 24개의
32비트 범용 레지스터가 있습니다 ( 그림 1(오른쪽)의 ). 이러한 하드웨어
스레드는 명령어 메모리(IRAM) 와 스크래치패드 메모리(WRAM) 를 공
유하여 피연산자를 저장합니다. DPU의 파이프라인 깊이는 14단계입니다 .
그러나 파이프라인의 마지막 세 단계(예: 그림 1(오른쪽)의 ALU4,
MERGE1 및 MERGE2) 만 다음 단계의 DISPATCH 및 FETCH 단계와 병렬
로 실행될 수 있습니다. 동일한 스레드 에서 명령을 수행합니다 . 따라서 동일
한 스레드의 명령은 11주기 간격으로 전달되어야 하며 파이프라인을 완전히
활용하려면 최소 11개의 스레드가 필요합니다 [231].
24KB IRAM은 최대 4,096개의 48비트 인코딩 명령어를 저장할 수 있습니다.
WRAM의 용량은 64KB입니다. DPU는 8, 16, 32 및 64비트 로드/저장 명령
을 통해 WRAM에 액세스할 수 있습니다 . ISA는 명령을 MRAM 뱅크에서
IRAM으로 이동하고 데이터를 MRAM 뱅크와 WRAM 사이에서 이동하기 위한
DMA 명령 [213] 을 제공합니다.
DPU의 주파수는 잠재적으로 400MHz 이상에 도달할 수 있습니다 [227].
400MHz에서 DPU당 가능한 최대 MRAM‑WRAM 대역폭은 약 800MB/s를
달성할 수 있습니다. 따라서 2,560개의 DPU가 포함된 구성의 최대 집계
MRAM 대역폭은 잠재적으로 2TB/s가 될 수 있습니다. 그러나 DPU는 2,556‑
DPU 설정에서는 350MHz로 실행되고 640‑DPU 시스템에서는 267MHz로
실행됩니다.
이러한 이유로 우리 설정에서 DPU당 가능한 최대 MRAM‑WRAM 대역폭 은
700MB/s(640‑DPU 설정에서 534MB/s) 이고 2,556 DPU에 대한 최대 집
계 대역폭은 1.7TB /s(333.75 640‑DPU 시스템에서는 GB/s).
2.3 DPU 프로그래밍 UPMEM 기반 PIM
시스템은 SPMD( Single Program Multiple Data ) [232] 프로그래밍 모델을
사용합니다. 여기서 tasklet이라고 불리는 소프트웨어 스레드는 (1) 동일한 코드를
실행하지만 서로 다른 데이터 조각에서 작동하며 (2) 다음을 수행할 수 있습니다.
런타임에 다양한 제어 흐름 경로를 실행합니다.
하드웨어 스레드 수가 24개이므로 DPU에서는 최대 24개의 태스크릿을 실
행할 수 있습니다. 프로그래머는 컴파일 타임에 DPU 당 태스크릿 수를 결정
하고 태스크릿은 각 DPU에 정적으로 할당됩니다.
동일한 DPU 내부의 태스크릿은 MRAM과 WRAM에서 서로 데이터를 공유
할 수 있으며 뮤텍스, 장벽, 핸드셰이크 및 세마포어를 통해 동기화할 수 있습
니다[233].
서로 다른 DPU의 태스크릿은 메모리나 직접적인 통신 채널을 공유하지 않습니
다. 결과적으로 직접 통신 하거나 동기화할 수 없습니다. 섹션 2.1에서 언급했듯
이 호스트 CPU는 DPU 간의 중간 데이터 통신을 처리하고 부분 결과를 최종 결과
로 병합합니다.
5
2.3.1 프로그래밍 언어 및 런타임 라이브러리. DPU 프로그램은 일부 라이브러리
호출과 함께 C 언어로 작성됩니다[198, 213].10 UPMEM SDK [234] 는 C 언
어 및 LLVM 컴파일 프레임워크 [235] 에서 지원되는 공통 데이터 유형을 지원합니
다 . 지원되는 명령어의 전체 목록을 보려면 독자에게 UPMEM 사용자 매뉴얼
[213]을 참조하세요.
UPMEM 런타임 라이브러리 [213] 는 (1) 명령을 MRAM 뱅크에서 IRAM으
로 이동하고 (2) MRAM 뱅크와 WRAM 간 데이터를 이동하는 라이브러리 호출
(즉, MRAM‑WRAM 전송을 위한 mram_read() , 및 WRAM‑MRAM 전송을 위
한 mram_write()) .
UPMEM 런타임 라이브러리는 또한 (1) 중요 섹션을 생성하는 뮤텍스
(mutex_lock(), mutex_unlock()) 를 잠그고 잠금 해제하고, (2) 모든 태스크
릿이 실행될 때까지 태스크릿 실행을 일시 중지하는 액세스 장벽 (barrier_wait())
을 수행하는 기능을 제공합니다. DPU에서 프로그램의 동일한 지점에 도달하고,
(3) 일대일 태스크릿 동기화를 가능하게 하는 핸드셰이크 (handshake_wait_for(),
handshake_notify())를 기다리고 알리고, (4) 세마포어를 증가 및 감소시킵니
다. 카운터(sem_give(), sem_take()).
C 언어를 사용하여 DPU를 프로그래밍하면 학습 곡선이 낮아지지만 프로
그래머는 몇 가지 과제를 처리해야 합니다 . 첫째, 최대 24개의 태스크릿을 실
행하는 수천 개의 DPU를 프로그래밍하려면 신중한 워크로드 분할 및 조정이
필요합니다. 각 태스크릿에는 프로그래머가 해당 목적으로 사용할 수 있는 태
스크릿 ID가 있습니다. 둘째, 프로그래머는 표준 메인 메모리와 MRAM 뱅크
간에 데이터를 명시적으로 이동해야 하며, CPU와 DPU 간의 데이터 일관성을
보장(즉, CPU와 DPU가 최신의 올바른 데이터 복사본을 사용하도록 보장)하
는 것이 프로그래머의 책임입니다. . 셋째, DPU는 캐시 메모리를 사용하지 않
습니다.
MRAM 뱅크와 WRAM 간의 데이터 이동은 다음과 같습니다.
프로그래머가 명시적으로 관리합니다.
2.3.2 일반 프로그래밍 권장 사항. UPMEM 프로그래밍 가이드 [213], 프레젠테
이션 [199], 백서[198] 에서 찾을 수 있는 UPMEM 기반 PIM 시스템의 일반적인
프로그래밍 권장 사항은 다음과 같습니다.
첫 번째 권장 사항은 호스트 CPU와의 빈번한 상호 작용을 피하면서 가능
한 한 긴 병렬 코드의 DPU 부분에서 실행하는 것입니다. 이 권장 사항은
좁은 메모리 버스(섹션 2.1) 를 통해 발생하는 CPU‑DPU 및 DPU‑CPU 전송
으로 인해 데이터 이동 병목 현상이 발생하며 [2–4, 7], PIM 패러다임이 이를
완화할 것을 약속합니다.
두 번째 권장 사항은 워크로드를 DPU가 독립적으로 (그리고 동시에) 작동하는
독립적인 데이터 블록으로 분할 하는 것입니다. 이 권장 사항은 병렬성을 최대화 하
고 DPU 간 통신 및 요구 사항을 최소화합니다.
CPU‑DPU 및 DPU‑CPU 전송을 사용하여 호스트 CPU를 통해 발생하므로
높은 오버헤드가 발생하는 동기화입니다 .
세 번째 권장 사항은 DPU가 실제 작업을 계속 수행할 만큼 워크로드가 충분
히 크다면 시스템에서 작동하는 DPU를 최대한 많이 사용하는 것입니다 . 이 권장
사항은 병렬성을 최대화하고 컴퓨팅 리소스의 활용도를 높입니다.
네 번째 권장 사항은 섹션 2.2에서 언급한 대로 세분화된 멀티스레드 파이프라
인을 완전히 활용하기 위해 각 DPU에서 최소 11개의 태스크릿을 시작하는 것입니
다.
10본 연구에서는 UPMEM SDK 2021.1.1[234]을 사용한다.
Machine Translated by Google
일반 프로그래밍 권장사항
1. 가능한 한 긴 병렬 코드의 DPU (DRAM 처리 장치 ) 부분 에서 실행
합니다 .
2. 워크로드를 DPU가 독립적으로 작동하는 독립 데이터 블록으로 분
할합니다.
3. 시스템에서 작동하는 DPU를 가능한 한 많이 사용합니다.
4. DPU당 최소 11개의 태스크릿 (즉, 소프트웨어 스레드)을 실행합
니다.
이 작업에서 우리는 UPMEM PIM 아키텍처에 대한 최초의 포괄적인 특성
화 및 분석을 수행합니다 . 이를 통해 (1) 이러한 프로그래밍 권장 사항을 검증
하고 해당 권장 사항이 보유한 워크로드 특성을 식별할 뿐만 아니라 (2) 추가
제안을 제안할 수 있습니다. 향후 PIM 소프트웨어 설계를 위한 프로그래밍 권
장 사항 및 제안 , (3) 보다 쉬운 프로그래밍은 물론 하드웨어를 더 많은 작업
부하에 광범위하게 적용 할 수 있는 향후 PIM 하드웨어 설계를 위한 제안 및
힌트를 제안합니다 .
3 성능 특성화
업멤 DPU
이 섹션에서는 다양한 아키텍처 한계와 병목 현상을 평가하기 위해 마이크로벤
치마크를 사용하여 UPMEM DPU 의 첫 번째 성능 특성을 제시합니다 . 섹션
3.1에서는 스트리밍 마이크로벤치마크 를 사용하여 DPU의 산술 연산 처리량
과 WRAM 대역폭을 평가합니다 . 섹션 3.2 에서는 MRAM과 WRAM 간의 지
속적인 대역폭을 평가합니다 . 섹션 3.3에서는 워크로드의 작업 강도가 DPU
의 산술 처리량에 미치는 영향을 평가합니다. 마지막으로 섹션 3.4 에서는 호스
트의 메인 메모리와 MRAM 뱅크 사이의 대역폭을 평가합니다 . 달리 명시 하
지 않는 한 섹션 2.1에 제시된 더 큰 2,556‑DPU 시스템에 대한 실험 결과를
보고합니다 . 이 섹션에서 확인된 모든 관찰 및 추세는 이전 640‑DPU 시스템
에도 적용됩니다 (이를 실험적으로 확인했습니다). 이 섹션에 사용된 모든 마이
크로벤치마크는 공개적으로 무료로 사용할 수 있습니다[214].
3.1 산술 처리량 및 WRAM 대역폭
DPU 파이프라인은 매 사이클마다 한 번의 정수 덧셈/뺄셈 작업을 수행할 수
있으며 파이프라인이 가득 찼을 때 매 사이클마다 최대 1회의 8바이트 WRAM
로드/저장을 수행할 수 있습니다 [199]. 따라서 350MHz에서 이론적 최대 산
술 처리량은 3억 5천만 MOPS(초당 연산 수)입니다. 이는 정수 추가 작업만 파
이프라인에 실행되고 이론적 최대 WRAM 대역폭은 2,800MB/s라고 가정합니
다. 이 섹션에서는 스트리밍 마이크로벤치마크(즉, 메모리 위치에 대한 단위 스
트라이드 액세스를 사용하는 벤치마크)를 통해 달성할 수 있는 산술 처리량과
지속적인 WRAM 대역폭을 평가하고 산술 처리량과 WRAM 대역폭이 마이크
로벤치 수에 따라 어떻게 달라지는지 평가합니다. 태스크릿이 배포되었습니다.
3.1.1 마이크로벤치마크 설명. 스트리밍 워크로드에서 산술 처리량과 WRAM
대역폭을 평가하기 위해 모든 태스크릿이 반복되는 마이크로벤치마크 세트
[214] 를 구현합니다.
6
WRAM의 배열 요소에 대해 읽기‑수정‑ 쓰기 작업을 수행합니다. WRAM 로
드, 산술 연산, WRAM 저장 및 루프 제어를 수행하는 데 걸리는 시간을 측정합
니다 . MRAM‑WRAM DMA 전송을 수행하는 데 걸리는 시간은 측정하지 않습
니다 ( 섹션 3.2에서 별도로 연구합니다).
산술 처리량. 산술 처리량을 위해 32비트 정수, 64비트 정수, 부동 소수점
및 복식에 대한 더하기, 빼기, 곱하기 및 나누기 연산을 검사합니다 . 부호 없
는 정수의 처리량은 부호 있는 정수의 처리량과 동일합니다 . 섹션 3.1의 시작
부분에서 지적했듯이 DPU 파이프라인은 파이프라인이 가득 찼다는 가정하에
매 사이클마다 하나의 정수 덧셈/뺄셈 작업을 수행할 수 있습니다 [ 199]. 그
러나 실제 워크로드는 정수 덧셈/뺄셈 연산만 실행하지 않습니다. 따라서
350MOPS라는 이론적 최대 산술 처리량은 실제 워크로드를 완전히 실행하기
에는 현실적이지 않습니다. DPU는 WRAM에 피연산자를 저장하므로 (섹션
2.2) 산술 처리량을 현실적으로 평가하려면 소스 피연산자를 읽고 대상 피연산
자를 쓰기 위해 WRAM에 액세스하는 것을 고려해야 합니다. WRAM에 대한
한 번의 액세스에는 한 번의 WRAM 주소 계산과 한 번의 로드/저장 작업이 포
함됩니다.
목록 1은 32비트 정수 덧셈의 처리량 평가를 위한 마이크로벤치마크의 예를
보여줍니다. 목록 1a는 C로 작성된 마이크로벤치마크를 보여줍니다. 피연산자는
bufferA에 저장되며, mem_alloc [213] (라인 2) 을 사용하여 WRAM에 할당
합니다 . 3행의 for 루프 는 bufferA 의 각 요소를 거쳐 스칼라 값 스칼라를 각
요소에 추가합니다 . 루프가 반복될 때마다 bufferA 의 한 요소를 시간 변수
temp 에 로드하고 (라인 4), 여기에 스칼라를 추가한 다음(라인 5), 결과를 다
시 bufferA 의 동일한 위치 에 저장합니다 (라인 6). 목록 1b에는 UPMEM의 컴
파일러 탐색기 [236] 를 사용하여 검사할 수 있는 컴파일된 코드가 나와 있습니
다 . 루프 에는 WRAM 주소 계산 (lsl_add, 3행), WRAM 로드 (lw, 4행), 추가
(add, 5행), WRAM 저장 (sw, 6행), 루프 인덱스 업데이트 (add, 7행)의 6개 명
령이 포함되어 있습니다. ) 및 조건부 분기 (jneq, 8행). 32비트 정수 빼기 (sub)
의 경우 스트리밍 루프의 명령어 수도 6개이지만 다른 작업 및 데이터 유형의 경
우 명령어 수가 다를 수 있습니다( 아래 참조).
스트리밍 마이크로벤치마크 루프의 명령 (목록 1b)이 주어지면 산술 연산
의 예상 처리량을 얻을 수 있습니다 . 6개의 명령어 중 하나만이 산술 연산 입
니다 ( 목록 1b의 5번째 줄에 추가). 파이프라인이 가득 찼다 고 가정하면
DPU는 매 사이클 마다 하나의 명령을 발행(및 폐기)합니다 [199]. 결과적으
로 하나의 산술 연산을 수행하려면 스트리밍 루프의 명령어만큼 많은 사이클
이 필요합니다. 루프의 명령어 수가 이고 DPU 빈도가 이면 방정식 1에 표현된
것처럼 OPS( 초당 작업 수 ) 단위로 산술 처리량을 계산합니다.
,
( )= (1)
32비트 정수 추가(목록 1)의 경우 350MHz에서 실행되는 DPU의 예상 산
술 처리량은 58.33 MOPS(초당 수백만 작업)입니다. 섹션 3.1.2 에서 실제 하
드웨어에서 이를 검증합니다 .
WRAM 대역폭. 지속적인 WRAM 대역폭을 평가하기 위해 STREAM 벤치마
크 [237]의 네 가지 버전을 조사합니다.
Machine Translated by Google

70 70
1 # 크기 256 정의
(a) INT32 (1 DPU) (b) INT64 (1DPU)
2 int * 버퍼 rA = mem_alloc ( SIZE * sizeof ( int ) ) ; 60 60

3 for ( int i = 0 ; i < SIZE ; i ++) {

50 50
추가하다
4 int temp = 버퍼 rA [i];
40 보결 40
5 온도 += 스칼라 ; 추가하다
멀
30 DIV 30 보결
6 버퍼 rA [i ] = 온도;
멀
7} 20 20 DIV
8
10 10

량(
리
처
술
산

량(
리
처
술
산
)SPOM

)SPOM
(a) C 기반 코드.
0 0

1
삼
5

삼
7

5
7
9

9
11

31

51

71

91

11

31

51

71

91
12

32

12

32
1 이동 r2 , 0
#태스크렛 #태스크렛
2 . LBB0_1 : // 루프 헤더
삼 lsl _ r3 추가 , r0 , r2 , 2 6 6
(c) 플로트 (1DPU) (d) 더블 (1DPU) 추가하다
4 lw r4 , r3 , 0 보결
5 5
5 r4 추가 r4 , r1 멀
,
4 추가하다 4 DIV
6sw r3 _ , 0 , r4
보결
7 r2를 추가하세요 , r2 , 1 삼 멀 삼

, 256 , DIV
8 jneq r2 . LBB0_1
2 2
9

(b) UPMEM DPU ISA에서 컴파일된 코드. 1 1

량(
리
처
술
산

량(
리
처
술
산
)SPOM

)SPOM
0 0

1
삼
5

삼
7

5
7
9

9
목록 1: 32‑의 처리량 평가를 위한 Microbenchmark

11

31

51

71

91

11

31

51

71

91
12

32

12

32
비트 정수 추가 [214]. #태스크렛 #태스크렛

그림 4: 산술 연산(ADD, SUB,
MUL, DIV)를 하나의 DPU에서 4가지 데이터 유형으로 사용: (a)
64비트 정수의 경우 COPY, ADD, SCALE 및 TRIAD입니다. INT32, (b) INT64, (c) FLOAT, (d) DOUBLE.
이러한 마이크로벤치마크는 2개(COPY, SCALE) 또는 3개(ADD,
TRIAD)는 스트리밍 방식(즉, 단위 스트라이드 또는 순차적 )으로 배열됩니다. ADD,
SCALE 및 TRIAD에 의해 수행되는 작업 첫째, 모든 산술 연산 및 데이터 유형의 처리량
각각 덧셈, 곱셈, 덧셈+곱셈이 있습니다 . 11개의 tasklet 후에 포화됩니다. 이 관찰은 섹션 2.2의 파이프라인 설명과 일치합니다.
DPU는 파이프라인을 완전히 활용하기 위해 태스크릿 전체에서 세분화된 멀티스레딩을 사
우리 실험에서는 지속 대역폭을 측정합니다. 용한다는 점을 기억하세요.
WRAM은 우리가 측정한 평균 대역폭입니다. 동일한 태스크릿의 명령어는 11주기 간격으로 전달되므로
비교적 오랜 시간 동안(즉, 스트리밍을 통해 스트리밍하는 동안) 11개의 태스크릿은 완전히 활용하는 데 필요한 최소 태스크릿 수입니다.
WRAM의 전체 배열). 파이프라인.
이론적으로 최대 WRAM 대역폭을 얻을 수 있습니다.
주요 관찰 1
숫자에 따라 달라지는 STREAM 마이크로벤치마크
각 버전에서 작업을 실행하는 데 필요한 지침 DRAM 처리의 산술 처리량
스트림의. DPU 파이프라인이 가득 찼다고 가정하면 다음과 같이 계산됩니다. 단위는 11개 이상의 tasklet으로 포화됩니다. 이 관찰은 ‑
초당 바이트 단위의 이론적 최대 WRAM 대역폭 이 방식은 다양한 데이터 유형(INT32, INT64,
(B/s)(수식 2), 여기서 는 읽은 총 바이트 수이고 UINT32, UINT64, FLOAT, DOUBLE) 및 연산(ADD,
쓰여진 것은 STREAM 버전의 명령 수입니다. SUB, MUL, DIV).
바이트를 읽고, 수정하고, 쓰는 것은 DPU 주파수입니다.

× 둘째, 덧셈/뺄셈 처리량은 58.56MOPS입니다.

( /)= (2) 32비트 정수 값의 경우(그림 4a), 64비트의 경우 50.16MOPS
정수 값(그림 4b). 내부 명령의 수
예를 들어 COPY는 WRAM 로드 (ld) 를 한 번 실행하고
32비트 정수 덧셈/뺄셈을 위한 스트리밍 루프는 6입니다(목록 1). 따라서
64비트 요소당 WRAM 저장소 (sd) 입니다. 이 두 가지 지침에는
350MHz에서 예상되는 처리량은 58.33MOPS입니다.
단일 tasklet을 실행하는 데 22주기가 소요됩니다. 파이프라인이 가득 차면
(수학식 1로 구함) 이는 우리가 측정한 것과 비슷합니다.
(즉, 11개 이상의 태스크릿이 있는 경우) 11 × 16 = 176바이트를 읽고
(58.56MOPS). 64비트 정수 덧셈/뺄셈이 포함된 루프
22주기로 작성되었습니다. 결과적으로 = 176 및 = 22이므로
7개 명령어 포함: 32비트 버전과 동일한 6개 명령어
=350MHz에서 COPY에 대한 이론적 최대 WRAM 대역폭,
게다가 캐리인 비트 (addc/subc) 를 사용한 덧셈/뺄셈
2,800MB/s입니다. 섹션 3.1.3에서 실제 하드웨어에서 이를 검증합니다.
64비트 피연산자의 상위 32비트입니다. 따라서 350MHz에서 예상되는 처리량은 50MOPS
3.1.2 산술 처리량. 그림 4는 하나의 DPU(MOPS 단위)에서 측정된 산술 처 이며 이는 우리가 측정한 것과도 가깝습니다.
리량이 DPU에 따라 어떻게 달라지는지를 보여줍니다. (50.16MOPS).
태스크렛의 수. 우리는 최대 1~24개의 tasklet을 사용합니다. 셋째, 정수 곱셈과 나눗셈의 처리량은
하드웨어 스레드 수. 정수 덧셈과 뺄셈에 비해 현저히 낮음
우리는 그림 4에서 네 가지 주요 관찰을 수행합니다. (그림 4a,b와 y축 스케일의 큰 차이에 주목하세요.

7
Machine Translated by Google

3000
그림 4c, d). 주된 이유는 하드웨어 비용 문제와 사용 가능한 금속 레이어의 제한된 수로 인해 스트림 (WRAM, INT64, 1DPU)
2500 2,818.98
DPU 파이프라인에 완전한 32 × 32비트 곱셈기가 포함되어 있지 않기 때문입니다 [199]. 32비 추가하다

2000 복사 1,682.46
트 피연산자의 곱셈과 나눗셈은 비트 이동과 덧셈을 기반으로 하는 두 개의 명령어 (mul_step, 규모
1500 삼인조
div_step) [213] 를 사용하여 구현됩니다 . 이러한 명령어를 사용하면 곱셈과 나눗셈을 수행하

MAR지
인
적
속
W

폭(
역
대
초
/B)M
1000
는 데 피연산자 값에 따라 최대 32사이클(32 mul_step 또는 div_step 명령어)이 걸릴 수 있
61.66
습니다. 500
42.03
0
123456 7 8 9 10 11 12 13 14 15 16

#태스크렛
곱셈과 나눗셈에 32사이클이 걸리는 경우 예상 처리량(식 1)은 10.94MOPS입니다. 이는 우리가
측정한 것과 유사합니다 (그림 4a에 표시된 대로 32비트 곱셈의 경우 10.27MOPS, 32비트 나 그림 5: 스트리밍 액세스 패턴을 위한 지속적인 WRAM 대역폭.

눗셈의 경우 11.27MOPS). . 64비트 정수 피연산자의 곱셈과 나눗셈을 위해 프로그램은 각각

123 및 191 명령어를 사용하여 두 개의 UPMEM 런타임 라이브러리 함수 (__muldi3,
__divdi3) [213, 238] 를 호출합니다 . 측정 결과에 따르면 이러한 64비트 연산의 예상 처리량
은 32비트 피연산자보다 훨씬 낮습니다(그림 4b에 표시된 대로 64비트 곱셈의 경우 2.56MOPS,
64비트 나눗셈의 경우 1.40MOPS).
넷째, 부동 소수점 연산의 처리량(그림 4c 및 4d 참조)은 정수 연산의 처리
량보다 10배 이상 낮습니다. 주된 이유는 DPU 파이프라인에 기본 부동 소수
점 ALU 기능이 없기 때문입니다. UPMEM 런타임 라이브러리는 소프트웨어에
서 이러한 작업을 에뮬레이트합니다 [213, 238].
결과적으로 각 32비트 또는 64비트 부동 소수점 연산에 대해 파이프라인에서
실행되는 명령 수는 수십 (32비트 부동 소수점 추가)에서 2000개(64비트 부
동 소수점 나누기) 사이입니다. 이는 낮은 처리량을 설명합니다. FLOAT 덧셈/
뺄셈/곱하기/나누기(그림 4c)의 경우 4.91/4.59/1.91/0.34 MOPS를 측정
하고 DOUBLE 덧셈/뺄셈/곱하기/나누기(그림 4d)의 경우
3.32/3.11/0.53/0.16 MOPS를 측정 합니다 .
주요 관찰 2
캐리인 비트를 사용한 추가 (addc) 하나 와 WRAM 저장소 (sd) 하나.
이 경우 파이프라인이 가득 차면 55주기 동안 11 × 24 = 264바이트에 액세
스합니다. 따라서 ADD의 이론적 최대 WRAM 대역폭은 1,680MB/s이며 이
는 우리가 측정한 것(1,682.46MB/s)과 유사합니다. SCALE 및 TRIAD의 최
대 지속 WRAM 대역폭은 훨씬 더 작습니다(각각 42.03 및 61.66MB/s). 이
는 이러한 마이크로벤치마크가 123개의 명령어가 있는 라이브러리 함수인 값
비싼 곱셈 연산을 사용하기 때문입니다(섹션 3.1.2).
셋째, 중요한 점은(그림 5에는 표시되지 않음) WRAM 대역폭이 액세스 패
턴 (스트리밍, 스트라이드, 랜덤)과 독립적이라는 것입니다.11 모든 8바이트
WRAM 로드 및 저장은 DPU 파이프라인이 가득 찼을 때 한 사이클을 사용하
기 때문입니다. 파이프라인에서 실행되는 다른 기본 명령과 같습니다 [199].
주요 관찰 3
DRAM 처리 장치의 내부 작업 메모리(WRAM)가 제공하는 지속적인 대역폭은 메모
리 액세스 패턴 (스트리밍, 스트라이드 또는 랜덤 액세스 패턴)과 무관합니다.

• DPU(DRAM 처리 장치)는 32비트 및 64비트 정수 덧셈 및 뺄셈을 위한 기본 하드

웨어 지원을 제공하여 이러한 작업의 처리량을 높입니다 .
모든 8바이트 WRAM 로드 및 저장에는 DRAM 처리 장치의 파이프
라인이 가득 찼을 때(즉, 11개 이상의 태스크릿이 있는 경우) 1사이
• DPU는 기본적으로 32비트 및 64비트 곱셈, 나눗셈, 부동 소수점 연산을 지원 하
클이 소요됩니다.
지 않습니다 .
이러한 작업은 UPMEM 런타임 라이브러리에 의해 에뮬레이션되므
로 처리량이 훨씬 낮아집니다. 3.2 MRAM 대역폭 및 대기 시간
DPU가 로드/저장 명령을 통해 WRAM의 데이터에 액세스할 수 있으려면 먼저
DMA 엔진을 통해 관련 MRAM 뱅크에서 WRAM으로 데이터를 전송해야 한다
3.1.3 지속적인 WRAM 대역폭. 그림 5는 지속 WRAM 대역폭이 태스크릿 수
에 따라 어떻게 달라지는지 보여줍니다. 는 점을 기억하세요. 이 섹션에서는 읽기 및 쓰기 대역폭(섹션 3.2.1), 스트리
밍 액세스 대역폭(섹션 3.2.2), 스트라이드/랜덤 액세스 대역폭 (섹션 3.2.3)
(1~16개의 태스크릿) 이 실험에서는 루프 제어 명령을 제외하고 가능한 가장
을 포함하여 MRAM에서 유지할 수 있는 대역폭을 평가합니다 .
높은 지속 WRAM 대역폭을 달성하기 위해 STREAM 마이크로벤치마크 의 루
프를 풀었습니다 . 우리는 세 가지 주요 관찰을 합니다.

첫째, 산술 처리량과 유사하게 WRAM 대역폭은 태스크릿 수인 11개 태스
크릿 이후에 포화되는 것을 관찰합니다.
DPU 파이프라인을 완전히 활용하는 데 필요합니다.
둘째, 측정된 최대 지속 WRAM 대역폭은 작업을 실행하는 데 필요한 명령
수에 따라 달라집니다 . COPY의 경우 2,818.98MB/s를 측정했는데, 이는 방
정식 2를 통해 얻은 이론적 최대 WRAM 대역폭인 2,800MB/s 와 유사합니다
(섹션 3.1.1 참조). ADD는 64비트 요소당 5개의 명령을 실행합니다 . 즉, 2개
3.2.1 읽기 및 쓰기 지연 시간과 대역폭. 이 실험에서는 단일 DMA 전송의 지
연 시간을 측정합니다.
11우리는 마이크로벤치마크( 오픈 소스 릴리스[214]의 일부로 도 제공 ) 를 사용하여 이 관찰을 검증했지만 간결성을 위해 여기
에 자세한 결과를 표시하지 않습니다 . 이 마이크로벤치마크는 WRAM, 및 의 세 가지 어레이를 사용합니다. 배열은 복사할 주
소 목록입니다(즉, [ [ ] ] = [ [ ] ]). 이 주소 목록은 (1) 단위 스트라이드(즉, [ ] = [ 1] + 1), ,(2) 스트라이드(즉, [ ] = [ 1]
+ ) 또는 (3) 무작위(예: , [ ] = ()). 주어진 수의 태스크릿과 배열 크기에 대해 모든 액세스 패턴(예: 단위 스트라이드, 스트라이
드 또는 무작위)에 대해 동일한 실행 시간을 측정하여 WRAM 대역폭이 액세스 패턴과 무관하다는 것을 확인합니다.

의 WRAM 로드 (ld), 1개의 추가 (add),

8
Machine Translated by Google

단일 태스크릿에 대해 서로 다른 크기를 지정하고 해당 MRAM 대역폭을 계산 주요 관찰 4

합니다. 이러한 DMA 전송은 mram_read(mram_source, • DRAM 처리 장치의 주 메모리(MRAM) 뱅크 액세스 대기 시간은 전송 크기에 따라
wram_destination, SIZE) 및 mram_write(wram_source, 선형적으로 증가합니다.
mram_destination, SIZE) 함수를 통해 수행됩니다 . 여기서 SIZE 는 전
송 크기(바이트)이며 UPMEM에 따라 8에서 2,048 사이의 8의 배수여야 합니 • 이론적 최대 MRAM 대역폭은 2입니다.
다. SDK 2021.1.1 [213]. 사이클당 바이트.

분석 모델링. 방정식 3의 선형 표현식을 사용하여 MRAM 액세스 대기 시간(주기 단위)을 분 우리는 그림 6에서 네 가지 관찰을 합니다.
석적으로 모델링할 수 있습니다 . 여기서 는 DMA 전송의 고정 비용, 가변 비용(즉, 바이트당 비용) 첫째, MRAM에 대한 읽기 및 쓰기 액세스가 대칭임을 관찰합니다 . 읽기 및
을 나타내고 는 전송 크기(바이트)를 나타냅니다. 쓰기 전송의 대기 시간과 대역폭은 지정된 데이터 전송 크기와 매우 유사합니
다.
둘째, 지속적인 MRAM 대역폭( 읽기 및 쓰기 모두)이 데이터 전송 크기에
( )=+× (삼) 따라 증가한다는 것을 관찰했습니다. 우리가 측정한 최대 지속 MRAM 대역폭
방정식 3을 사용하여 MRAM 액세스 대기 시간을 모델링한 후 방정식 3.2.1을 사용하여
은 읽기의 경우 628.23MB/s 이고 쓰기 전송의 경우 633.22MB/s입니다(둘
MRAM 대역폭(B/s)을 분석적으로 모델링할 수 있습니다. 여기서 는 DPU 주파수입니다. 다 2,048바이트 전송의 경우).
이러한 관찰을 바탕으로 MRAM 대역폭 활용을 최대화하기 위한 일반적인 권
장 사항 은 액세스된 모든 데이터가 사용될 때 큰 DMA 전송 크기를 사용하는
× 것입니다. 방정식 3.2.1 에 따르면 이론적 최대 MRAM 대역폭은 350MHz의
/)= =
( DPU 주파수에서 700MB/s입니다(고정 전송 비용이 없다고 가정, 즉 = 0). 우
리의 측정값은 이 이론적 최대값의 12% 이내입니다 .
×
= (4)
+×

측정. 그림 6은 측정된 MRAM 읽기 및 쓰기 대기 시간과 대역폭이 전송 크기에 따라 어떻게 프로그래밍 권장 사항 1

달라지는지, 그리고 측정된 대기 시간이 위에서 개발한 분석 모델을 얼마나 잘 따르는지 보여줍니
DRAM 처리 장치의 주 메모리(MRAM) 뱅크와 내부 작업 메모리
다.
(WRAM) 간의 데이터 이동을 위해 액세스된 모든 데이터가 사용될
628.23
때 큰 DMA 전송 크기를 사용하십시오.
1000
MRAM 읽기 2048년

100
512 셋째, MRAM 대기 시간이 8바이트와 128바이트 전송 사이에서 천천히 변하는 것을 관찰했
습니다 . 방정식 3에 따르면 128바이트에 대한 읽기 지연 시간은 141사이클이고 8바이트에 대
10 128
한 읽기 지연 시간은 81사이클입니다. 즉, 전송 크기는 16배 증가하는 반면 대기 시간은 74%만
간(
시
연
지
기
)주
폭(
역
대
초
/B)M

1 32 증가합니다. 그 이유는 데이터 전송 크기가 작은 경우 전송 지연의 고정 비용( )이 가변 비용 ( × )

8
61

46
23

을 지배하기 때문입니다. 데이터 전송 크기가 큰 경우 고정 비용( )이 가변 비용( × )을 지배하지

652

4201

840년
2

않으며 실제로는 그 반대가 되기 시작합니다. 읽기 전송의 경우(77사이클)는 8바이트 읽기에 대

데이터 전송 크기(바이트)
한 대기 시간의 95%, 128바이트 읽기에 대한 대기 시간의 55%를 나타냅니다. 이러한 관찰을 바
633.22
1000 탕으로 프로그래머를 위한 권장 사항 중 하나 는 작은 데이터 전송 크기를 사용할 때 128바이트
MRAM 쓰기 2048년
제한 내에서 필요한 것보다 더 많은 바이트를 가져오는 것입니다. 이렇게 하면 나중에 액세스하
100 기 위해 WRAM에서 데이터를 찾을 확률이 높아져 향후 MRAM 액세스가 제거됩니다. 프로그램
512
은 새로운 작은 데이터 전송을 실행하기 전에 이전 MRAM‑WRAM 전송에서 원하는 데이터를 가
10 128 져왔는지 간단히 확인할 수 있습니다.
간(
시
연
지
기
)주
폭(
역
대
초
/B)M

1 32
8
61

46
23

652

4201

840년
2

데이터 전송 크기(바이트)

그림 6: 8~2,048바이트 사이의 데이터 전송 크기에 대한 MRAM 읽기 및 쓰기 대기 시간(로그

규모) 및 대역폭(로그 규모). 검은색 파선은 선형 모델을 사용한 예상 대기 시간을 나타냅니다(수 프로그래밍 권장 사항 2
학식 3).
DRAM 처리 장치의 주 메모리(MRAM) 뱅크와 내부 작업 메모리(WRAM) 간의 소규
모 전송의 경우 128바이트 제한 내에서 필요한 것보다 더 많은 바이트를 가져옵니
측정 결과 mram_read 의 경우 약 77사이클 , mram_write 의 경우 약 다. 이렇게 하면 나중에 액세스하기 위해 WRAM에서 데이터를 찾을 가능성이 높아집
61사이클인 것으로 나타났습니다 . 두 가지 전송 유형 모두 값은 0.5사이클/B 니다(즉, 프로그램은 새 MRAM 액세스를 실행하기 전에 원하는 데이터가 WRAM에
입니다. 의 반대는 이론적 최대 MRAM 대역폭(고정 비용 = 0으로 가정)이며, 있는지 확인할 수 있습니다 ).
결과적으로 2B/사이클이 됩니다. 방정식 3.2.1의 분석 모델을 사용하여 추정
된 대기 시간 값 (그림 6의 검은색 점선)은 대기 시간 측정값( 그림 6의 연한 파
란색 선)과 정확하게 일치합니다.
넷째, MRAM 대기 시간 증가가 느리기 때문에 MRAM 대역폭은 8~128바
이트 사이에서 거의 선형적으로 확장됩니다. 128바이트 이후에는

9
Machine Translated by Google

MRAM 대역폭이 포화되기 시작합니다. MRAM 대역폭이 큰 데이터 전송 크기 섹션 2.2에서 파생된 MB/s입니다. 2,556개 DPU에 대해 측정된 총 지속 대역폭
에서 포화되는 이유는 대역폭과 대기 시간의 역관계와 관련이 있습니다 (식 은 1.6TB/s입니다. 640‑DPU 시스템에서 지속 MRAM 대역폭은 DPU당
3.2.1). 데이터 전송 크기가 증가함에 따라 전송 지연의 고정 비용( )은 가변 비 470.50MB/s(이론적 최대값 = 534MB/s)로 측정되어 640 DPU에 대해 총 지
용( × ) 에 비해 무시할 수 있게 됩니다 . 예를 들어 읽기 전송(77사이클)의 경 속 MRAM 대역폭은 301GB/s가 됩니다.
우 각각 512바이트, 1,024바이트, 2,048바이트 읽기 전송에 대한 MRAM 대
기 시간의 23%, 13%, 7%에 불과합니다 . 결과적으로 MRAM 읽기 대역폭은 둘째, COPY‑DMA의 MRAM 대역폭은 두 개의 태스크릿으로 포화됩니다. DMA 엔진은 한
512바이트 전송 에 비해 1,024바이트 및 2,048바이트 전송의 경우 13%와 번에 하나의 데이터 전송만 수행할 수 있지만 [231] COPY‑DMA에서 두 개 이상의 태스크릿을
17%만 증가합니다 . 이러한 관찰에 따르면, 액세스된 모든 데이터가 사용될 사용하면 이전 DMA 요청이 완료될 때 DMA 엔진을 사용 중으로 유지하기 위해 항상 DMA 요청
때 권장되는 데이터 전송 크기는 프로그램의 WRAM 사용량에 따라 달라집니 이 대기열 에 추가되는 것을 보장합니다. 가장 높은 MRAM 대역폭을 달성합니다.
다. WRAM의 크기는 64KB로 제한되어 있기 때문입니다. 예를 들어, DPU 프
로그램의 각 태스크릿이 MRAM에 저장된 3개의 서로 다른 어레이의 데이터에
대해 3개의 임시 WRAM 버퍼를 할당해야 하는 경우 2,048바이트 데이터 전송 셋째, COPY 및 ADD에 대한 MRAM 대역폭은 각각 4개 및 6개 태스크릿으
을 사용하려면 각 WRAM 버퍼의 크기가 2,048바이트가 되어야 합니다. 이는 로 포화됩니다. 즉, 파이프라인을 완전히 활용하는 데 필요한 11개 태스크릿보
태스크릿 수를 10개로 제한합니다. 이는 < 11.3 ×2,048 이므로 11개 태스크 다 빠릅니다. 이러한 관찰은 이러한 마이크로벤치마크가 MRAM(명령 파이프라
릿 중 권장되는 최소 64개 (섹션 2.3.2 및 3.1.2)보다 적습니다 . 이 경우 인이 아닌 )에 대한 액세스로 제한된다는 것을 나타냅니다. COPY 벤치마크가 4
1,024바이트 데이터를 사용합니다. 측정에 따르면(그림 6 참조 ) 2,048바이 개 미만의 태스크릿을 사용하는 경우 파이프라인 명령(예: WRAM 로드/저장)의
트 전송의 대역폭은 1,024바이트 전송의 대역폭보다 4%만 높기 때문에 전송 대기 시간은 MRAM 액세스(예: MRAM‑ WRAM 및 WRAM‑MRAM DMA 전
이 선호됩니다 . 송) 의 대기 시간보다 깁니다 . 4개의 태스크릿 이후에는 이러한 추세가 바뀌고
MRAM 액세스 대기 시간이 길어집니다.

그 이유는 MRAM 액세스가 직렬화되어 MRAM 액세스 대기 시간이 태스크릿 수

에 따라 선형적으로 증가하기 때문입니다. 따라서 4개의 태스크릿 이후 전체 대
프로그래밍 권장 사항 3 기 시간은 파이프라인 대기 시간을 숨기는 MRAM 액세스 대기 시간에 의해 지배
DRAM 간 데이터 전송 크기를 선택하세요. 됩니다. 결과적으로 COPY의 지속적인 MRAM 대역폭은 COPY‑DMA와 마찬가
지로 가장 높은 MRAM 대역폭의 4개 태스크릿으로 포화됩니다.
처리 장치의 주 메모리(MRAM) 뱅크와 내부 작업 메모리(WRAM)는 프로그램의
WRAM 사용량을 기반으로 합니다. 이는 지속적인 MRAM 대역폭과 숫자 사이의 균
형을 유지하기 때문입니다.
6개의 태스크릿이 있는 ADD 벤치마크에도 유사한 관찰이 적용됩니다.
넷째, SCALE 및 TRIAD의 지속 MRAM 대역폭은 COPYDMA, COPY 및
ADD 의 대역폭보다 약 10배 더 작습니다 . 또한 SCALE 및 TRIAD의 MRAM
DRAM 처리 장치에서 실행할 수 있는 태스크릿 수 (제한된 WRAM 용량에 따라 결
대역폭은 11개의 태스크릿, 즉 파이프라인을 완전히 활용하는 데 필요한 태스크
정됨)
릿의 수로 포화됩니다 . 이 관찰은 SCALE 및 TRIAD 성능이 MRAM 액세스가
3.2.2 지속적인 스트리밍 액세스 대역폭. 이 실험에서는 섹션 3.1.1에 설명된 아닌 파이프라인 처리량에 의해 제한된다는 것을 나타냅니다. SCALE 및 TRIAD
동일한 네 가지 버전의 STREAM 벤치마크 [237] 를 사용 하지만 측정에 는 섹션 3.1.2에 설명된 대로 mul_step 명령어를 기반으로 하는 값비싼 곱셈
MRAM‑WRAM DMA 전송 시간을 포함합니다 . 우리는 또한 을 사용한다는 점을 기억하세요 . 결과적으로 파이프라인의 명령 실행은 MRAM
액세스보다 대기 시간이 훨씬 더 깁니다. 따라서 SCALE 및 TRIAD는 파이프라
복사 벤치마크인 COPY‑DMA는 DPU 코어에서 WRAM 로드/저장을 수행하지 인 처리량에 의해 제한되므로 SCALE 및 TRIAD의 최대 지속 WRAM 대역폭(그
않고 MRAM에서 WRAM으로 데이터를 복사하고 그 반대로 복사합니다. 우리는 림 5)은 최대 지속 MRAM 대역폭(그림 7)과 동일합니다.
1024바이트 DMA 전송을 사용합니다. 태스크릿 수를 1에서 16으로 확장합니
다. 태스크릿은 총체적으로 2M 8바이트 요소(총 16MB)를 스트리밍하며, 이는
태스크릿 전체에 균등하게 나뉩니다.

그림 7은 MRAM 스트리밍 액세스 대역폭이 태스크릿 수에 따라

어떻게 달라지는지 보여줍니다. 주요 관찰 5

700 스트림 (MRAM, INT64, 1DPU) • 스트리밍 벤치마크(COPY‑DMA, COPY, ADD)를 위한 DRAM 처리 장치의 주 메
600 모리(MRAM) 뱅크에 대한 액세스 지연 시간이 파이프라인 지연 시간 (즉, 산술 연산
624.02
500 추가하다
및 WRAM 액세스 의 실행 지연 시간 )보다 큰 경우 성능은 DPU(DRAM 처리 장치)
400 복사
MAR지
형
속
M

의 용량은 11개보다 작은 태스크릿(즉, 소프트웨어 스레드) 수로 포화됩니다.

폭(
역
대
초
/B)M

COPY‑DMA
300
규모
200 삼인조 61.59
100 42.01

0
1 2 4 5 6 7 8 9 10 11 12 13 14 15 16
삼
이는 메모리 바인딩된 워크로드입니다. • 스트리밍 벤치마
#태스크렛
크(SCALE, TRIAD)에 대한 파이프라인 대기 시간이 MRAM 액세스 대기 시간보다
그림 7: 스트리밍 액세스 패턴을 위한 지속적인 MRAM 대역폭.
큰 경우 DPU 성능은 11개의 태스크릿에서 포화됩니다. 이는 컴퓨팅 바인딩된 워크
로드입니다.
우리는 네 가지 주요 관찰을 합니다.
첫째, COPY‑DMA의 지속 MRAM 대역폭은 624.02MB /s로 이론상 최대 대
역폭(700MB/s)에 가깝습니다.

10
Machine Translated by Google
3.2.3 지속적인 스트라이드 및 랜덤 액세스 대역폭. 우리는 평가한다 ‑
스트라이드 및 랜덤 액세스의 지속적인 MRAM 대역폭을 사용했습니다.
패턴.
MRAM의 스트라이드 액세스 대역폭을 평가하기 위해 우리는 스트라이드
방식으로 MRAM에 액세스하는 새로운 마이크로벤치마크를 작성하는 실험을
고안했습니다. 마이크로벤치마크는 일정한 스트라이드(즉, 연속 메모리 액세
스 사이의 일정한 거리)로 배열에 액세스하여 동일한 스트라이드를 사용하여
배열의 요소를 다른 배열로 복사합니다. 우리는 거친 DMA와 미세한 DMA라
는 두 가지 버전의 마이크로벤치마크를 구현하여 거친 MRAM 액세스와 미세
한 MRAM 액세스를 모두 테스트합니다. 성긴 DMA 에서 마이크로벤치마크는
DMA를 통해 MRAM에 있는 어레이의 큰 연속 세그먼트(1024B)에 액세스하
고, 스트라이드 액세스는 WRAM에서 발생합니다. 대략적인 DMA 접근 방식
은 최신 CPU 하드웨어가 수행하는 작업(즉, 주 메모리에서 큰 캐시 라인을 읽
고 캐시에서 이를 통과하는 작업)과 유사합니다.
세분화된 DMA에서 마이크로벤치마크는 MRAM의 마이크로벤치마크에서 사
용할 데이터만 DMA를 통해 전송합니다.
세분화된 DMA 접근 방식을 사용하면 DMA 요청이 늘어나지만 MRAM과 WRAM 간에 전
송되는 총 데이터 양은 줄어듭니다.
MRAM의 무작위 액세스 대역폭을 평가하기 위해 우리는 배열의 무작위 위
치에서 읽기‑수정‑쓰기 작업을 수행하는 GUPS 벤치마크 [239] 를 구현합니
다. GUPS의 무작위 메모리 액세스는 공간적으로 상관되지 않기 때문에 대량
의 데이터를 가져와도 이점을 얻지 못하기 때문에 무작위 액세스에는 세분화
된 DMA 만 사용합니다 .
실험에서는 태스크릿 수를 1에서 16까지 확장합니다.
태스크릿은 (1) 대략적인 스트라이드 액세스, (2) 세분화된 스트라이드 액세
스 또는 (3) 세분화된 랜덤 액세스를 사용하여 MRAM의 배열에 집합적으로
액세스합니다. 각 배열에는 2M 8바이트 요소 (총 16MB)가 포함되어 있으며
태스크릿 전체에 균등하게 나뉩니다.
그림 8은 지속적인 MRAM 대역폭이 액세스 패턴(스트라이드 및 랜덤 액세
스)과 태스크릿 수에 따라 어떻게 달라지는지 보여줍니다.
우리는 네 가지 주요 관찰을 합니다.
먼저, 최대 지속 MRAM 대역폭을 측정하면 대략적인 DMA(16개의 태스크
릿 및 스트라이드 1, 그림 8a)의 경우 622.36MB/s이고 세분화된 DMA의 경
우 72.58MB/s( 16개의 태스크릿, 그림 8b)입니다. ). 거친 DMA와 미세한
DMA의 지속 MRAM 대역폭 값의 차이는 다양한 전송 크기에 대한 MRAM 대
역폭의 차이와 관련이 있습니다 (섹션 3.2.1에서 분석). 대략적인 DMA는
1,024바이트 전송을 사용하는 반면, 세분화된 DMA는 8바이트 전송을 사용
합니다.
둘째, 성긴 DMA(그림 8a)의 지속적인 MRAM 대역폭은 스트라이드가 커짐
에 따라 감소하는 것을 관찰했습니다 . 이는 전송된 데이터의 효과적인 활용으
로 인해 발생하며, 스트라이드가 클수록 감소합니다(예: 스트라이드 4는 전송
된 데이터의 1/4만 효과적으로 사용됨을 의미함).
셋째, 성긴 DMA 접근 방식은 더 작은 스트라이드에 대해 더 높은 유지
MRAM 대역폭을 갖는 반면, 세밀한 DMA 접근 방식은 더 큰 스트라이드에 대
해 더 높은 유지 MRAM 대역폭을 갖습니다.
성긴 DMA의 스트라이드가 클수록 사용되지 않은 채 가져온 데이터의 양이 많
아지므로 세분화된 DMA는 스트라이드가 클수록 더 효율적이 됩니다. 이 실험
에서, 대략적인 DMA 접근 방식은 1과 8 사이의 스트라이드에 대해 세분화된
DMA 접근 방식보다 더 높은 지속 MRAM 대역폭을 달성합니다. 스트라이드
가 16 이상인 경우, 세분화된 DMA 접근 방식은
11
더 높은 지속 MRAM 대역폭을 달성합니다. 이는 스트라이드가 클수록 마이크
로벤치마크에서 실제로 사용되는 전송된 데이터의 비율이 작아지기 때문입니다
(즉, 효과적으로 사용되는 MRAM 대역폭이 작아짐). 16의 스트라이드와 대략
적인 DMA를 사용하는 마이크로벤치마크는 가져온 데이터의 16분의 1만 사용
합니다. 결과적으로, 우리는 대략적인 DMA에 대해 지속 MRAM 대역폭을
38.95MB/s로 측정했습니다. 이는 최대 지속 MRAM 대역폭인 622.36MB/s
의 16분의 1에 불과하고 미세 DMA의 지속 MRAM 대역폭보다 낮습니다. 세
분화된 DMA (72.58MB/s).
넷째, 랜덤 액세스를 위한 최대 지속 MRAM 대역폭은 72.58MB/s입니다
(그림 8b에 표시된 대로 16개의 태스크릿 포함). 이 대역폭 값은 스트라이드
액세스에 대한 세분화된 DMA 접근 방식의 최대 MRAM 대역폭(예: 그림 8b
에 표시된 대로 16개의 태스크릿 및 스트라이드 4,096의 72.58MB/s)과 매
우 유사합니다 . 왜냐하면 마이크로벤치마크는 세분화된 DMA를 사용하기 때
문입니다. 무작위 접근을 위해.
이러한 관찰을 바탕으로 프로그래머 는 스트라이드가 작은 워크로드에는 대략적인 DMA 접
근 방식을 사용하고 스트라이드가 크거나 임의 액세스 패턴이 있는 작업에는 세분화된 DMA 접
근 방식을 사용하는 것이 좋습니다 .
프로그래밍 권장 사항 4
• 16개의 8바이트 요소보다 작은 스트라이드를 갖는 스트라이드 액세스 패턴의 경
우 DRAM 처리 장치의 주 메모리(MRAM) 뱅크에서 큰 연속 청크(예: 1,024바이트)
를 가져옵니다. • 스트라이드가 더 큰 스트라이드 액세스 패턴 과 무작위 액세스 패
턴 의 경우 MRAM 뱅크에서 필요
한 데이터 요소만 가져옵니다.
3.3 산술 처리량과 작업 강도 비교 세분화된 다중 스레드 아키텍처 [205‑209]
로 인해 DPU
는 파이프라인의 명령 실행 대기 시간과 MRAM 액세스 대기 시간 [199, 213]
을 겹칩니다. 결과적으로 전체 DPU 성능은 주요 지연 시간(명령 실행 지연 시
간 또는 MRAM 액세스 지연 시간)에 의해 결정됩니다. 우리는 섹션 3.2.2의 실
험 결과에서 이 동작을 관찰합니다. 여기서 지배적인 대기 시간(파이프라인 대
기 시간 또는 MRAM 액세스 대기 시간)이 다양한 버전의 STREAM 벤치마크
에 대한 지속적인 MRAM 대역폭을 결정합니다[237].
DPU 아키텍처를 더 자세히 이해하기 위해 MRAM 액세스 수에 따라 파이
프라인 명령 수를 변경 하고 산술 처리량 측면에서 성능을 측정하는 새로운 마
이크로벤치마크를 설계합니다( 섹션 3.1에 정의된 MOPS 기준). .1). MRAM
액세스당 파이프라인 명령 수를 변경함으로써 MRAM 액세스 지연 시간이 지
배적인 마이크로벤치마크 구성(즉, 메모리 바인딩된 영역)에서 파이프라인 지
연 시간이 지배적인 마이크로벤치마크 구성(즉, 컴퓨팅 바인딩된 영역)으로 이
동합니다.
우리의 마이크로벤치마크에는 MRAM‑WRAM DMA 전송, WRAM 로드/저
장 액세스 및 다양한 수의 산술 연산이 포함됩니다. 마이크로벤치마크 에서
MRAM‑WRAM DMA 전송 횟수는 일정하므로 총 MRAM 대기 시간은 다음과
같습니다.
Machine Translated by Google

700 90
(a) 거친 스트라이드 (MRAM, 1 DPU) (b) 세분화된 스트라이드 및 랜덤 (MRAM, 1 DPU)
622.36 80
600 72.58
70
500
60
400 대략적인 DMA ‑ 1개의 태스크릿 50
대략적인 DMA ‑ 2개의 태스크릿

초(
대략적인 DMA ‑ 4개의 태스크릿 40
초(

/B)M
300
/B)M

대략적인 DMA ‑ 8개의 태스크릿

대략적인 DMA ‑ 16개의 태스크릿 30
200 세분화된 DMA ‑ 태스크릿 1개
20 세분화된 DMA ‑ 2개의 태스크릿
100 77.86 세분화된 DMA ‑ 4개의 태스크릿

MAR대
인
적
속
지
폭
역
M
MAR대
인
적
속
지
폭
역
M

10 세분화된 DMA ‑ 8개의 태스크릿

세분화된 DMA ‑ 16개 태스크릿
0 0
1

1
2

2
8

8
4

4
61

61
46

46
23

23
821

821
652

652
215

215
4201

4201
840년
2

840년
2
6904

6904

SPUG
)SPUG(
의
위
작
무
보폭 보폭

그림 8: (a) 성긴 스트라이드 및 (b) 세분화된 스트라이드 및 랜덤 액세스 패턴에 대한 지속적인 MRAM 대역폭.

그것도 꾸준하게. 그러나 실행되는 명령의 대기 시간은 다음과 같습니다. 즉, 가져온 32개의 32비트 요소마다 1번 곱셈) 연산 강도입니다. 이 결과는 DPU가 기본적으로
파이프라인은 다양한 산술 연산 수에 따라 달라집니다. 워크 로드용으로 설계된 컴퓨팅 기반 프로세서임을 보여줍니다.
우리의 실험은 산술 처리량이 어떻게 달라지는지 보여주는 것을 목표로 합니다.
운영 강도가 높습니다. 우리는 운영 강도를 다음과 같이 정의합니다. 데이터 재사용이 적습니다.
액세스된 바이트당 수행된 산술 연산 수
주요 관찰 6
MRAM(OP/B). 섹션 3.1.2에서 설명했듯이 UPMEM PIM 아키텍처의 산술
연산은 여러 명령어를 사용하여
DRAM 처리의 산술 처리량
실행하다. 실험은 지붕선 모델 [215] 에서 영감을 얻었습니다 . 장치(DPU)가 낮거나 매우 낮은 작동 상태에서 포화됩니다.
성능을 보여주는 성능 분석 방법론
강도 (예: 32비트 요소당 1개의 정수 추가). 따라서,
산술 강도(실행된 산술 명령)의 함수인 프로그램 (초당 실행되는 산술 명령)
DPU는 기본적으로 컴퓨팅 바인딩된 프로세스입니다.
미안.
메모리에서 액세스되는 바이트당)과 비교하여 프로그램의
대부분의 실제 워크로드는 UPMEM PIM 아키텍처에서 컴퓨팅에 바인딩될 것으로
머신의 최고 성능(컴퓨팅에 의해 결정됨) 예상됩니다 .
처리량 및 L3 및 DRAM 메모리 대역폭).
그림 9는 대표적인 데이터 유형 및 작업에 대한 산술 처리량 대 작업 강도
의 결과를 보여줍니다. (a) 셋째, 데이터 유형에 대한 처리량 포화점이 더 낮습니다.
32비트 정수 덧셈, (b) 32비트 정수 곱셈, (c) 32비트 작업당 더 많은 지침이 필요한 작업. 을 위한
부동 소수점 덧셈, (d) 32비트 부동 소수점 곱셈. 예를 들어 32비트 곱셈의 처리량(그림 9b)은 다음과 같습니다.
기타 데이터 유형에 대한 결과(64비트 정수 및 64비트 부동 소수점) 최대 32개의 mul_step 명령어(섹션 3.1.2)가 필요하며 포화 상태입니다.
~에 1 OP/B, 32비트 추가에 대한 처리량(그림 9a),
산술 연산(뺄셈과 나눗셈)도 비슷합니다. 32
트렌드. 작업 강도를 매우 낮은 값 (작업/바이트, 즉 512 32비트당 하나의 작 기본적으로 지원됩니다(단일 추가 명령 이 필요함 ).
1 4 로 포화 1
업) 에서 변경합니다.
2048년
OP/B. 부동 소수점 연산은 다음보다 먼저 포화됩니다.
가져온 요소)를 높은 값(바이트당 8개 작업, 즉 가져온 32비트 요소마다 32 정수 연산(수십에서 수백 개의 명령어가 필요하기 때문): 32비트 부동 소수점
개 작업)으로 변환하고 결과를 측정합니다. 추가(그림 9c) 및
1 그리고 1
다양한 태스크릿 수(1~16)에 대한 처리량입니다. 곱셈(그림 9d)은 각각 OP/B에서 포화됩니다. 64 128

우리는 그림 9에서 네 가지 주요 관찰을 수행합니다. 넷째, 계산 경계 영역(즉, 포화 지점 이후)에서 산술 처리량이 11로 포화됨
첫째, 그림 9의 네 가지 플롯은 (1) 메모리 바인딩을 보여줍니다. 을 관찰합니다.
지역(연산 처리량이 운영에 따라 증가하는 곳) 태스크릿은 태스크릿을 완전히 활용하는 데 필요한 태스크릿의 수입니다.
강도) 및 (2) 계산 경계 영역(여기서 산술 관로. 반면에, 메모리 바인딩된 영역에서는 메모리 대역폭이 부족하기 때문에
처리량은 각 태스크릿 수에 대해 최대값에서 일정합니다. 처리량이 더 적은 태스크릿으로 포화됩니다.
주어진 수의 태스크릿에 대해 파이프라인의 명령어 실행 지연 시간이 MRAM 파이프라인이 완전히 활용되기 전에 한도에 도달합니다. 예를 들어,
1
을 초과할 때 메모리 바인딩 영역과 계산 바인딩 영역 사이의 전환이 발생합니 매우 낮은 작동 강도 값 (≤ 64 OP/B), 처리량
다. 32비트 정수 덧셈은 단 두 개의 태스크릿으로 포화됩니다.
지연 시간. 우리는 메모리 바인딩 영역과 컴퓨팅 바인딩 영역 사이의 COPY‑DMA가 있는 섹션 3.2.2의 관찰과 일치합니다.

전환이 일어나는 작업 강도 값을 참조합니다. 대역폭은 두 개의 tasklet으로 포화됩니다. 그러나 운영상의

1
지역은 처리량 포화 지점으로 발생합니다. OP/B의 강도는64액세스된 64B(16개의 32비트 정수)마다 한 번만 추가되므
1
둘째, 산술 처리량은 낮은 수준에서 포화됩니다(예: 정수 추 4
OP/B 로 매우 낮습니다 . 우리는 더 높은 것을 기대합니다
1
가, 즉 매 32비트 요소당 1개의 정수 추가). 대부분의 현실 세계에서 운영 강도(예: OP/B보다 4 큼)
1
가져옴) 또는 매우 낮음(예: 부동128 소수점 곱셈의 경우 OP/B, 작업 부하 [184, 215] 및 이에 따른 산술 처리량 포화
실제 워크로드에는 11개의 태스크릿이 있습니다.

12
Machine Translated by Google

64.00 1123456 1123456

64.00
11123456 1123456
11123456 1123456 10
1089 1089 1089 1089 1089
32.00 (a) INT32, ADD (1 DPU) 789
6 67 67 67 32.00 (b) INT32, MUL (1 DPU)
67 6
5 7 5 5 5 5
4 5 4 4 4 4
16.00 3 4 3 3 3 3 16.00
2
10123456789 6 5 4 3 2
32 2 2 2 2 1123456
1123456 10
1123456 1123456 1123456 1123456 1123456
1123456 10
8.00 1012345656789 4 3 2 8.00 1089 1089 10 10 10 10
101234563456789 2 789
11213456 10 789789 6 6
1 1 1 1 1 1 1 6 6 67
5
4.00
1012345623456789

1 4.00 5 5 5 7
1 4 4 4 4 5 89 89 89 89
3 3 3 3 4 6 6 6 6
1012345623456789
2.00 2.00 2 2 2 32 75432 75432 75432 75432
11
2
101234566789 5 4 3 2
10123456456789 3 2
량(
리
처
술
산
일
케
스
그
로

량(
리
처
술
산
일
케
스
그
로
,SPO)M

,SPO)M
1.00 1.00 1 1 1 1 1 1 1
1012345623456789 1
101234563456789 2

1 1 1
1
0.50 1012345623456789 1 0.50 1
1012345623456789 1

0.25 1012345623456789 1 0.25

1012345623456789 1

0.13 1 1012345623456789
0.13
1012345623456789 1

0.06 0.06

0.03 0.03

1 2 4 8 1 2 4 8
1/4096 1/2048 1/1024 1/512 1/256 1/128 1/64 1/32 1/16 1/8 1/4 1/2 1 2 4 8 1/4096 1/2048 1/1024 1/512 1/256 1/128 1/64 1/32 1/16 1/8 1/4 1/2 1 2 4 8
운영 강도(OP/B) 운영 강도(OP/B)

64.00 64.00

32.00 (c) FLOAT, ADD (1 DPU) 32.00 (d) FLOAT, MUL (1 DPU)

16.00 16.00

8.00 8.00
1123456 1123456 1123456
1123456 10 1123456 10 1123456 10 1123456 10 1123456 10
4.00 10
11123456 11123456

1089 1089
4.00
1089 1089
789 789 789 789 789
789
6 67 6 6 6 6 6 6 67 67
2.00 101234566789
5 5 7 5 5 5 5 5 5 5 2.00
5 4 4 5 4 4 4 4 4 4 4 1123456 10 1123456 10 1123456 10
1123456 1123456 1123456 1123456
4 3 3 3 3 3 3 3
3 3 4 10 89 10 89 10 89 10 89

1.00 3 1.00 11123456 10 789789 789 789

6
량(
리
처
술
산
일
케
스
그
로

량(
리
처
술
산
일
케
스
그
로
,SPO)M

,SPO)M
2 2 2 2 2 2 2 6 6 6 1123456 1089 61123456
7 1089 61123456
7 1089 6 76 7 67 67 67
2 2 32 5 5 5 5 5 5 5 5 5 5 5
2 4 4 4 4 4 4 4 4 4 4
10123456456789 3 2 4
0.50 0.50 3 3 3 3 3 3 3 3 3 3 3
1 1 1 1 1 1
10123456456789
101234563456789 2

1 1 1 1 3
1 2 2 2 2 2 2 2 2 2 2 2
1 10123456789 6 5 4 3 2
0.25 1 0.25 2
101234563456789 2

1 1 1 1 1 1 1 1 1 1 1
1012345623456789 1

1 1
0.13 0.13
101234563456789 2 1
1012345623456789 1

0.06 0.06
1
0.03 0.03

1 2 4 8 1 2 4 8
1/4096 1/2048 1/1024 1/512 1/256 1/128 1/64 1/32 1/16 1/8 1/4 1/2 1 2 4 8 1/4096 1/2048 1/1024 1/512 1/256 1/128 1/64 1/32 1/16 1/8 1/4 1/2 1 2 4 8
운영 강도(OP/B) 운영 강도(OP/B)

그림 9: (a) 32비트 정수 덧셈, (b) 32비트 정수 곱셈, (c) 32비트 부동 소수점 덧셈 및 (d) 32비트 부동 소수점 곱셈에 대한 산술 처리량 대 연산 집약도. 각 점 안의 숫자
는 태스크릿 수를 나타냅니다. x축과 y축은 모두 로그 스케일입니다.

부록(섹션 9.1)에서는 이러한 결과에 대한 다른 관점을 제시하며, 다양한 작업 뱅크(예: CPU‑DPU) 또는 MRAM 뱅크에서 호스트 메인 메모리(예: DPU‑CPU)
강도에서 태스크릿 수에 따라 산술 처리량이 어떻게 달라지는지 보여줍니다. 로 전송됩니다. 병렬 전송에는 동일한 병렬 전송에 관련된 모든 MRAM 뱅크에 대
한 전송 크기가 동일해야 한다는 제한( UPMEM SDK 2021.1.1 [213]) 이 있습
니다.
3.4 CPU‑DPU 통신 병렬 CPU‑DPU 전송 (dpu_broadcast_to) 의 특별한 경우는 동일한 버퍼를
메인 메모리에서 모든 MRAM 뱅크로 브로드캐스트합니다.
PIM 지원 메모리의 호스트 CPU와 DPU는 메모리 버스를 통해 통신합니다. 호스
트 CPU는 그림 1과 같이 (1) 메인 메모리에서 MRAM(즉, CPU‑ DPU)으로 입
이 섹션에서는 호스트 메인 메모리와 MRAM 뱅크 간의 모든 유형
의 CPU‑DPU 및 DPU‑CPU 전송의 지속 대역폭을 측정합니다 . 우리
력 데이터를 전송하고, (2) MRAM에서 메인 메모리 (즉, DPU‑CPU)로 결과를
다시 전송하기 위해 MRAM 뱅크에 액세스할 수 있습니다. 보여줍니다. 이러한 데
는 두 가지 다른 실험을 수행합니다. 첫 번째 실험은 단일 MRAM 뱅
이터 전송을 각각 CPU‑DPU 및 DPU‑CPU 전송이라고 합니다 . 섹션 2.1 에서
크에서 다양한 크기의 버퍼를 전송합니다. 따라서 우리는 하나의
MRAM 뱅크에 대해 서로 다른 크기의 CPU‑DPU 및 DPU‑CPU 전
설명한 대로 이러한 데이터 전송은 직렬(즉, 여러 MRAM 뱅크에 걸쳐 순차적으로
송의 지속적인 대역폭을 얻습니다.
수행됨) 또는 병렬(즉, 여러 MRAM 뱅크에서 동시에 수행됨)일 수 있습니다.
이 실험에서는 dpu_copy_to 및 dpu_copy_from을 사용 하고 전송 크기를
UPMEM SDK [213] 는 직렬 및 병렬 전송 기능을 제공합니다. 직렬 전송의 경
8바이트에서 32MB까지 변경합니다. 두 번째 실험에서는 MRAM 뱅크당 32MB
우 dpu_copy_to 는 호스트 메인 메모리의 버퍼를 특정 MRAM 뱅크(즉, CPU‑
크기의 버퍼를 동일한 랭크 내의 1~64개 MRAM 뱅크 세트 간에 전송합니다. 브
DPU)로 복사하고, dpu_copy_from은 한 MRAM 뱅크의 버퍼를 호스트 메
로드캐스트 CPU‑DPU 전송 ( dpu_broadcast_to) 을 포함하여 직렬 및 병렬
인 메모리 (즉, DPU‑CPU)로 복사합니다. 병렬 전송의 경우 프로그램은 두 가지
전송(dpu_push_xfer)을 모두 실험합니다 . 따라서 우리는 1에서 64 사이의 동
기능을 사용해야 합니다 . 먼저, dpu_prepare_xfer는 특정 MRAM 뱅크에 서
일한 순위에 있는 여러 MRAM 뱅크에 대해 직렬/병렬/브로드캐스트 CPU‑DPU
로 다른 버퍼를 할당하여 병렬 전송을 준비합니다 . 둘째, dpu_push_xfer는 실
전송 및 직렬/병렬 DPU‑CPU 전송의 지속적인 대역폭을 얻습니다 .
제 전송을 시작하여 병렬로 실행합니다 . dpu_push_xfer 의 한 인수는 병렬 데
이터 전송이 호스트 주 메모리에서 MRAM으로 발생하는지 여부를 정의합니다.

그림 10은 두 실험의 지속된 대역폭 결과를 보여줍니다 .

13
Machine Translated by Google

1.0000 CPU‑DPU(직렬) DPU‑CPU(직렬)

CPU‑DPU(병렬) DPU‑CPU(병렬) 16.88
CPU‑DPU 16.00
CPU‑DPU(브로드캐스트)
0.1000 8.00 6.68
DPU‑CPU
4.00
4.74
0.0100 2.00
1.00
폭
역
대

폭
역
대
0.0010 0.50 0.27
모
규
그
로
,s(
/B)G

모
규
그
로
,s(
/B)G
‑UP지
형
속
D
C

0.25

‑UP지
형
속
D
C
0.0001 0.13 0.12
8

K2
23

K8
0.06
821

2
215

K23

8
4
M23
K821

61

46
K215

23
(a) DPU 1개 (b) 1등급
데이터 전송 크기(바이트) #DPU

그림 10: (a) CPU‑DPU(호스트 메인 메모리에서 하나의 MRAM 뱅크로) 및 DPU‑CPU(하나의 MRAM 뱅크에서 호스트 메인 메모리로)의 지속 대역폭(로그 스케일 x 및 y축)은 하나의 서로 다른 크기
로 전송됩니다. DPU 및 (b) 직렬/병렬/브로드캐스트 CPU‑DPU(여러 MRAM 뱅크에 대한 호스트 주 메모리) 및 직렬/병렬 DPU‑CPU(호스트 주 메모리에 대한 여러 MRAM 뱅크)는 1‑64 세트에 대해
32MB를 전송합니다. 한 등급 내의 DPU.

우리는 7가지 주요 관찰 사항을 제시 하나의 DPU보다 높습니다. DPU‑CPU 전송의 경우 DPU 64개에서
합니다.12 첫째, 단일 DPU(그림 10a)에 대한 CPU‑DPU 및 DPU 1개로의 지속적인 대역폭 증가는 38.76배입니다.
DPU‑CPU 전송의 지속 대역폭은 8바이트에서 512바이트 사이의
전송 크기에서 유사합니다. 전송 크기가 512바이트보다 큰 경우 주요 관찰 8
CPU‑DPU 전송의 지속 대역폭은 DPU‑CPU 전송의 대역폭보다 높
습니다 . 우리가 평가한 최대 전송 크기(32MB )의 경우 CPU‑DPU 호스트 메인 메모리와 DRAM 처리 장치의 메인 메모리(MRAM) 뱅크 간 병렬 CPU‑
및 DPU‑CPU 대역폭은 각각 0.33GB/s 및 0.12GB /s입니다. DPU 및 DPU‑CPU 전송의 지속 대역폭은 랭크 내의 DRAM 처리 장치 수에 따라
증가합니다.
둘째, 단일 DPU(그림 10a)에 대한 CPU‑DPU 및 DPU‑CPU 전송의 지
속 대역폭은 8 바이트에서 2KB 사이에서 선형적으로 증가하며 더 큰 전송 크
기에서는 포화되는 경향이 있습니다.

주요 관찰 7
다섯째, 직렬 및 직렬 전송 모두에서 CPU‑DPU와 DPU‑CPU 전송의 지속 대역폭
사이에 큰 차이가 있음을 관찰했습니다.
호스트 메인 메모리와 DRAM 처리 장치의 메인 메모리(MRAM) 뱅크 간의 CPU‑
DPU 및 DPU‑CPU 전송이 클수록 지속 대역폭이 높아집니다. 병렬 전송. 이러한 차이점은 UPMEM SDK 2021.1.1 [231]에서 CPU‑DPU 및 DPU‑
CPU 전송의 서로 다른 구현으로 인해 발생합니다 . CPU‑DPU 전송은 비동기식 x86
AVX 쓰기 명령어 [ 240] 를 사용하는 반면 , DPU‑CPU 전송은 동기식 AVX 읽기 명령
어 [240] 를 사용합니다. 결과적으로 DPU‑CPU 전송은 CPU‑DPU 전송만큼 많은 메
모리 액세스를 유지할 수 없으며, 이로 인해 CPU‑DPU 전송보다 직렬 및 병렬 DPU‑
셋째, 한 등급(그림 10b)의 경우 직렬 CPU‑DPU 및 DPU‑CPU 전송 의 지속 대역폭 CPU 전송의 유지 대역폭이 낮아집니다.
은 서로 다른 등급에 대해 균일하게 유지됩니다.
DPU 수. 이러한 전송은 순차적으로 실행되므로 지연 시간은 DPU 수(즉, 전송된 총 데이터 양)
에 비례하여 증가합니다. 결과적으로 지속 대역폭은 증가하지 않습니다.
여섯째, 브로드캐스트 CPU‑DPU 전송의 지속 대역폭은 최대 16.88GB/s에 이릅니
다. 이 최대 유지 대역폭이 병렬 CPU‑DPU 전송보다 훨씬 높은 이유 중 하나는 호스트
넷째, 병렬 전송의 지속 대역폭은 DPU 수에 따라 증가하여 64 DPU에서 가장 높은 CPU 의 캐시 계층 구조에서 더 나은 집약성입니다 [231]. 브로드캐스트 전송은 동일한
지속 대역폭 값에 도달합니다. 최대 지속 CPU‑DPU 버퍼를 모든 MRAM 뱅크에 복사하여 CPU 캐시 계층 구조의 시간적 지역성을 증가시키
는 반면, 병렬 CPU‑DPU 전송은 서로 다른 버퍼를 서로 다른 MRAM 뱅크에 복사합니
우리가 측정한 대역폭은 6.68GB/s이고, 최대 지속 DPU‑CPU 대역폭은 4.74GB/s입니 다. 이러한 버퍼는 CPU 캐시 계층 구조에서 누락될 가능성이 높으며 MRAM 뱅크에 복
다. 그러나 DPU 개수에 따른 지속 대역폭의 증가는 준선 형적이라는 것을 알 수 있습니 사되기 전에 메인 메모리에서 CPU 캐시로 가져와야 합니다 .
다. 64개 DPU에 대한 지속 CPU‑DPU 대역폭은 20.13배입니다.

일곱째, 전체 순위에 대한 모든 실험에서 유지 대역폭은 이론적인 최대 대역보다 낮

12CPU‑DPU 및 DPU‑CPU 전송에 대한 측정 및 관찰은 플랫폼에 따라 다르며(즉, 측정 및 관찰
습니다.
은 다른 호스트 CPU에 대해 변경될 수 있음) UPMEM SDK에 따라 다릅니다(예: CPU‑DPU/
DPU‑CPU 전송은 UPMEM SDK의 향후 릴리스에서 변경될 수 있습니다. DDR4‑2400 DIMM의 너비(19.2GB/s) [226]. 이러한 대역폭 손실은 UPMEM
SDK가 전체 64비트 단어를 동일한 MRAM 뱅크에 매핑하는 데 사용하는 전
예를 들어, 640‑DPU 시스템(표시되지 않음)의 대역폭 측정은 2,556‑DPU 시스템의 대역폭 측정과
다릅니다(그러나 우리가 관찰한 추세는 두 시스템 모두에서 유사함을 발견했습니다 ). 치 라이브러리 [199] 에 기인합니다 (섹션 2.1).

14
Machine Translated by Google

주요 관찰 9 벤치마크 선택은 표 2에 표시된 대로 (1) PIM에 대한 적합성, (2) 도메인 다

양성, (3) 메모리 액세스, 계산 및 통신/동기화 패턴 의 다양성 등 여러 기준을
호스트 메인 메모리와 CPU 간 병렬 CPU‑DPU 전송의 지속적인 대역폭
기반으로 합니다. 메모리 경계를 연구하여 PIM에 대한 이러한 워크로드의 적합
성을 확인합니다 . 우리는 섹션 3.3에 설명된 대로 루프라인 모델 [215] 을 사
DRAM 처리 장치의 주 메모리(MRAM) 뱅크는 MRAM 뱅크 간 병렬 DPU‑CPU
용하여 작업 부하의 CPU 버전에 대한 메모리 경계를 정량화합니다.
전송의 지속 대역폭보다 높습니다.

UPMEM에서 CPU‑DPU 및 DPU‑CPU 전송의 서로 다른 구현으로 인

해 호스트 메인 메모리 그림 11은 Intel Advisor[242]가 포함된 Intel Xeon E3‑1225 v6 CPU
런타임 라이브러리. [241] 의 루프라인 모델을 보여줍니다 . 이 실험에서는 표 3의 각 워크로드에
브로드캐스트 CPU‑DPU의 지속 대역폭 대한 첫 번째 데이터세트를 사용합니다 (섹션 5 참조).
전송(즉, 동일한 버퍼가 여러 MRAM 뱅크에 복사됨) 은 CPU 캐시 계층 구조 의
시간적 지역성이 높기 때문에 병렬 CPU‑DPU 전송(즉, 서로 다른 버퍼가 서로 다
16 최고의 컴퓨팅 성능
른 MRAM 뱅크에 복사됨)보다 높습니다 .
8 MLP
GEMV 버지니아

4 L3
학사 HST
2 TS 북서쪽
유니

능(
성
)SPOG
1 SpMV TRNS
4 PRIM 벤치마크 실제 PIM 아키텍처를 위 0.5 SEL
빨간색
BFS
주사
한 최초의 벤치마크 제품군인 오픈 소스 PrIM (Processing‑In‑Memory) 벤치 0.25 음주
마크 제품군에 포함된 벤치마크를 제시합니다 . PrIM 벤치마크는 공개적으로 무료 0.125
0.01 0.1 1 10
로 이용 가능합니다[214].
산술 강도(OP/B)

각 벤치마크에 대해 이 섹션에는 여러 DPU가 있는 UPMEM 기반 PIM 시스
템에서의 구현 에 대한 설명이 포함되어 있습니다 . 표 2는 벤치마크를 요약한
것입니다. 벤치마크가 속한 애플리케이션 도메인별로 벤치마크를 그룹화합니
다. 각 애플리케이션 도메인 내에서 (1) PIM 구현의 점진적 복잡성(예: GEMV
보다 먼저 VA를 설명함) 및 (2) 알파벳 순서를 기준으로 벤치마크를 정렬합니
다 . 우리는 표 2의 벤치마크 순서를 이 논문의 나머지 부분 전체에서 일관되게
사용합니다.
각 벤치마크에 대해 표에는 (1) 이 문서의 나머지 부분에서 사용하는 벤치마크
의 짧은 이름, (2) 벤치마크의 메모리 액세스 패턴(순차, 스트라이드, 무작위),
(3) 계산 패턴(작업 및 (4) PIM 구현의 통신/동기화 유형(DPU 내, DPU 간).
DPU 내 통신의 경우 표에서는 벤치마크에서 사용하는 장벽, 핸드셰이크, 뮤텍
스 등의 동기화 기본 요소를 지정합니다(섹션 2.3.1).
그림 11: Intel Xeon E3‑1225 v6 CPU의 14개 PrIM 워크로드 CPU 버전에 대한 루프라
인 모델.
그림 11에서 PrIM 워크로드의 모든 CPU 버전이 루프라인 모델의 메모리 경계 영역(즉,
DRAM 대역폭 선과 최대 컴퓨팅 성능 사이 교차점의 왼쪽에 있는 음영 영역)에 있음을 알 수
있습니다. 맨스 라인). 따라서 이러한 워크로드는 모두 메모리에 의해 제한됩니다. 우리는
PrIM 워크로드의 14개 CPU 버전이 모두 잠재적으로 PIM에 적합하다는 결론을 내렸습니다
[184]. 다음에 는 각 PrIM 벤치마크 와 해당 PIM 구현에 대해 간략하게 설명합니다.
4.1 벡터 추가
벡터 덧셈(VA) [243] 은 두 개의 벡터 를 입력으로 사용하여 요소별 덧셈을 수행합니다.

우리의 PIM 구현은 입력 벡터 를 시스템의 DPU 수만큼 동일한 크기의 청

PrIM 벤치마크의 모든 구현은 섹션 2.3.2에 제시된 일반 프로그래밍 권장 사
크 로 나누고 선형 할당(즉, DPU에 할당된 청크)을 만듭니다. 호스트 CPU는
항을 따릅니다. 우리의 목표 는 극도로 최적화된 구현을 제공하는 것이 아니라 일
두 벡터의 한 청크를 각 DPU의 MRAM 뱅크에 로드합니다. 각 DPU 내에서
반적인 프로그래밍 권장 사항을 따르고 합리적인 프로그래머 노력으로 PIM 지원 순환 방식으로 태스크릿 의 요소 블록을 태스크릿에 할당합니다 (즉, DPU당
메모리의 리소스를 잘 활용하는 구현을 제공하는 것입니다. UPMEM 기반 PIM
총 태스크릿 수에 대해 태스크릿 %에 할당된 블록). 각 태스크릿 (1)은 WRAM
시스템 에 적합한 둘 이상의 구현을 설계할 수 있는 여러 벤치마크의 경우 모든 대
에서 요소 블록을 이동하고, (2) 요소별 추가를 수행하고, (3) 결과를 MRAM
체 구현을 개발하고 비교합니다. 결과적으로 우리는 두 가지 벤치마크인 이미지 히
뱅크로 이동합니다. Tasklet은 DPU에 할당된 전체 청크가 처리될 때까지 필
스토그램(HST)과 접두사 합계 (SCAN)의 두 가지 버전을 제공합니다. 부록(섹션
요한 만큼 반복됩니다 . DPU에서의 실행이 끝나면 CPU는 MRAM 뱅크에서
9.2)에서는 이러한 버전을 비교 하고 각 벤치마크의 각 버전이 더 높은 성능을 나
호스트 메인 메모리로 출력 벡터 청크를 검색하고 완전한 출력 벡터를 구성합니
타내는 사례(예: 데이터 세트 특성)를 찾습니다 . 우리는 또한 세 가지 버전의
다.
Reduction(RED)을 설계하고 개발합니다. 그러나 세 가지 버전 중 하나는 항상
다른 두 버전보다 더 높은(또는 적어도 동일한) 성능을 제공하기 때문에 이를 별도
의 벤치마크로 제공하지 않습니다 (부록, 섹션 9.2 참조).13

4.2 행렬‑벡터 곱셈 행렬‑벡터 곱셈(GEMV)

[243] 은 크기가 × 인 행렬과 크기가 ×1 인 벡터를 다음과 같이 취하는 조밀 한
선형 대수 루틴입니다.

13동일한 벤치마크의 일부로 RED의 세 가지 버전을 제공합니다. 사용자는 컴파일러 플래 입력하고 이들 사이의 곱셈을 수행하여 결과적으로 새로운 × 1 벡터를 생성합니다.
그를 통해 테스트하려는 버전을 선택할 수 있습니다.

15
Machine Translated by Google

표 2: PrIM 벤치마크.

메모리 액세스 패턴 계산 패턴 통신/동기화

도메인 기준 짧은 이름
순차 스트라이드 랜덤 운영 데이터 유형 내부 DPU DPU 간

벡터 추가 버지니아 예 추가하다 int32_t

조밀한 선형 대수학 GEMV 예 추가, 다
행렬‑벡터 곱셈 uint32_t
희소 선형 대수 희소 행렬‑벡터 곱셈 SpMV 예 예 중 추가, 뜨다
선택하다 SEL 예 다중 추가, 비 int64_t 핸드셰이크, 배리어 int64_t 예
데이터베이스
고유한 유니 예 교 추가, 비교 핸드셰이크, 배리어 int64_t 예

이진 검색 학사 예 예 비교하다
데이터 분석
시계열 분석 TS 예 추가, 하위, 다중, div int32_t
그래프 처리 너비 우선 검색 BFS 예 예 비트 논리 uint64_t 추가, mul, 장벽, 뮤텍스 예
신경망 다층 퍼셉트론 MLP 예 비교 int32_t
생물정보학 니들만‑분쉬 북서쪽 예 예 추가, 하위, 비교 int32_t 추가 장벽 예

이미지 히스토그램(짧음) HST‑S 예 예 uint32_t uint32_t 장벽, 장벽 예

이미지 처리
이미지 히스토그램(긴) HST‑L 예 예 추가하다 뮤텍스 int64_t 장벽 int64_t 핸 예
절감 빨간색 예 예 추가 드셰이크, 장벽 int64_t 핸 예
접두사 합계(스캔‑스캔‑추가) 스캔‑SSA 예 추가 드셰이크, 장벽 int64_t 뮤텍스 예
병렬 프리미티브 예 추가 예
접두사 합계(감소‑스캔‑스캔) SCAN‑RSS
행렬 전치 TRNS 예 예 추가, 하위, 멀

GEMV의 PIM 구현은 매트릭스를 전체로 분할합니다. SEL의 PIM 구현은 전체 스토리지에 걸쳐 어레이를 분할합니다.
시스템에서 사용 가능한 DPU 수를 지정하여 고정된 수의 DPU를 할당합니다. 시스템에서 사용할 수 있는 DPU. DPU 좌표 내부의 태스크릿
입력 벡터가 복제되는 동안 각 DPU에 연속 행 악수 사용(섹션 2.3.1) 먼저, 각 태스크릿은 블록을 이동합니다.
모든 DPU에 걸쳐. 호스트 CPU는 각 연속 행 세트를 할당합니다. WRAM에 요소를 추가합니다. 둘째, 각 태스크릿은 요소를 필터링하고
선형 할당을 사용하여 DPU에 할당(즉, DPU에 할당된 행 집합) 필터링된 요소의 수를 계산합니다. 셋째, 각 tasklet이 통과합니다.
). 각 DPU 내에서 태스크릿은 세트의 컴퓨팅을 담당합니다. 본질적으로 접두사 합계를 수행하는 핸드셰이크 기반 통신을 사용하여 필터링된 요소 수
해당 DPU에 할당된 행 수입니다. 우리는 연속된 부분 집합을 할당합니다. 를 다음 태스크릿으로 보냅니다.
각 tasklet에 DPU에 할당된 행 집합의 행(예: MRAM에서 데이터를 저장할 위치를 결정하는 작업 [249‑251]
tasklet에 할당된 행의 하위 집합). 먼저, 각 tasklet은 다음을 읽습니다. 필터링된 요소 그런 다음 태스크릿은 필터링된 요소를 다음 위치로 이동합니다.
입력 행렬의 한 행과 두 행의 요소 블록 MRAM. 넷째, 호스트 CPU는 최종 병합을 수행합니다.
벡터를 생성하고 이러한 요소를 WRAM에 배치합니다. 둘째, 각각 직렬 DPU‑CPU 전송을 통해 각 DPU에서 반환된 필터링된 배열,
tasklet은 해당 요소의 곱셈과 누적을 수행합니다. 병렬 DPU‑CPU 전송은 가능하지 않습니다.
행의 끝에 도달할 때까지 첫 번째 단계로 점프합니다. 제삼, DPU는 필터링된 요소의 수를 다르게 반환할 수 있습니다.
각 태스크릿은 MRAM에 곱셈의 합계를 저장합니다. 네번째,
각 태스크릿은 이 세 단계를 가능한 횟수만큼 반복합니다.
하위 집합의 행. 다섯째, 각 DPU는 연속된 덩어리를 생성합니다. 4.5 독특함
출력 벡터의 요소. CPU는 출력 벡터를 검색합니다. Unique(UNI) [248] 는 각 그룹에 대해
전체 출력 벡터를 청크하고 빌드합니다. 동일한 값을 가진 연속 배열 요소는 다음을 제외한 모든 요소를 제거합니다.
이 요소 중 첫 번째.
4.3 희소 행렬‑벡터 곱셈 UNI의 PIM 구현은 유사한 접근 방식을 따릅니다.
희소 행렬‑벡터 곱셈(SpMV) [244] 은 희소 행렬에 조밀한 벡터를 곱하는 희소 선형 대수 SEL에. 주요 차이점은 UNI에 필요한 보다 복잡한 핸드셰이크 기반 통신에 있습니다. 고
루틴입니다 . 유번호 외에도
SpMV의 PIM 구현은 Compressed Sparse를 사용합니다. 요소의 경우 각 태스크릿은 마지막 고유 요소의 값을 전달해야 합니다.
행렬을 표현하기 위한 행(CSR) 저장 형식 [245–247] . 첫 번째, 다음 태스크릿으로 이동하세요. 이런 식으로 다음 tasklet은 다음 여부를 확인할 수 있습니다.
호스트 CPU는 매트릭스 행을 DPU에 균등하게 분배합니다. 첫 번째 요소는 전체 배열의 맥락에서 고유하거나 그렇지 않습니다.
다음과 같이 선형 할당(즉, DPU 에 할당된 행 집합)을 사용합니다.
GEMV(섹션 4.2). 각 DPU 내에서 행렬의 행은 다음과 같습니다.
tasklet 전체에 균등하게 분배됩니다(즉, 다음에 할당된 행의 하위 집합). 4.6 이진 검색
GEMV와 동일한
, 태스크릿). 입력 벡터는 다음과 같이 복제됩니다. 이진 검색(BS) [252] 은 정렬된 배열을 입력으로 사용하여 다음을 찾습니다.
DPU. 각 tasklet은 행의 하위 집합을 입력과 곱합니다. 정렬된 배열 내 일부 쿼리 값의 위치.
벡터를 생성하고 출력 벡터의 연속적인 청크를 생성합니다. ~에 이진 검색의 PIM 구현은 정렬된 결과를 배포합니다.
DPU의 실행이 끝나면 CPU는 DPU 전체에 배열합니다. 각 DPU 내에서 태스크릿은 다음을 담당합니다.
MRAM 뱅크에서 호스트 메인으로 출력 벡터 청크 할당된 쿼리 값의 하위 파티션입니다. 먼저, 각 tasklet은 다음을 확인합니다.
전체 출력 벡터를 구성하기 위해 메모리를 사용합니다. 찾을 할당된 쿼리 값 세트를
MRAM 뱅크에서 WRAM으로 이동하고 for 루프를 사용하여 반복합니다.
4.4 선택
둘째, 각 태스크릿은 이진 검색 알고리즘을 수행하여 이동합니다.
Select (SEL) [248] 은 입력 배열이 주어지면 다음을 수행하는 데이터베이스 연산자입니다. 현재 값에 따라 왼쪽에서 오른쪽으로 또는 그 반대로
주어진 입력 조건자에 따라 배열 요소를 필터링합니다. 우리의 찾다. 셋째, 태스크릿은 하나의 쿼리를 찾으면 알고리즘을 중지합니다.
SEL 버전은 조건자를 만족하는 요소를 제거합니다. 값. 넷째, DPU 실행이 끝나면 호스트는
그렇지 않은 요소를 유지합니다. CPU는 발견된 쿼리 값의 위치를 검색합니다.

16
Machine Translated by Google
4.7 시계열 분석 시계열 분석(TS) [253]
은 주어진 시계열의 하위 시퀀스 간의 변칙과 유사점을 찾는 것을 목표로 합니
다 . 우리 버전의 시계열 분석은 데이터 소스에서 나오는 하위 시퀀스(또는 쿼
리 시퀀스)를 잘 알려진 시계열과 비교하는 스트리밍과 같은 방식으로 작동하
는 알고리즘인 Matrix Profile [254] 을 기반으로 합니다. 예상되는 동작.
시계열 분석의 PIM 구현은 DPU 전체에서 시계열을 나누고, 이들 사이에
필요한 중첩을 추가하고, 태스크릿 전체에서 쿼리 시퀀스를 복제하여 시계열
과 비교합니다. 시계열의 다양한 조각이 다양한 태스크릿에 할당됩니다. 첫째,
각 태스크릿은 시계열 조각과 쿼리 시퀀스의 내적을 수행합니다. 둘째, 각 태스
크릿은 z 정규화 유클리드 거리를 계산하여 시계열 조각과 쿼리 시퀀스 간의 유
사성을 계산합니다 [254]. 셋째, 각 태스크릿은 계산 된 유사성을 지금까지 발
견된 최소 유사성(또는 애플리케이션에 따라 최대값)과 비교하고, 계산된 유사
성이 새로운 최소값(또는 최대값)이면 업데이트합니다. 넷째, DPU에서의 실행
이 끝나면 호스트 CPU는 모든 DPU에서 최소(또는 최대) 유사성 값과 해당
위치를 검색 하고 전체 최소(또는 최대) 및 해당 위치를 찾습니다.
4.8 너비 우선 탐색
BFS(Breadth‑First Search) [255] 는 그래프의 각 노드에 주어진 소스 노드
로부터의 거리를 표시하는 그래프 알고리즘입니다 . 우리 버전 에서는 모든 모서
리의 가중치가 동일하므로 거리는 모서리 수를 나타냅니다.
BFS의 PIM 구현은 그래프를 나타내는 인접 행렬의 CSR(Compressed
Sparse Row) [245‑247] 표현을 사용합니다. 인접 행렬의 각 요소 ( , ) 는 꼭
지점과 가 모서리로 연결되어 있는지 여부를 나타냅니다. 정점은 DPU 전체에 고
르게 분산되며, 각 DPU는 자신이 소유한 정점에 대한 인접 목록을 수신합니다.
정점의 이웃 목록에는 연결된 정점의 정점 ID가 포함됩니다.
모서리로 꼭지점으로. 각 DPU는 비트 벡터로 표시되는 그래프에서 방문한 정
점 목록의 자체 로컬 복사본을 유지합니다. BFS 알고리즘의 각 반복이 끝나
면 호스트 CPU는 방문한 정점 목록의 모든 로컬 DPU별 복사본을 병합합니
다 . 방문한 정점의 전체 목록을 프론티어라고 합니다.
각 반복이 시작될 때 호스트 CPU는 전체 현재 경계를 모든 DPU에 브로드캐
스트합니다. 각 DPU는 현재 프론티어를 사용하여 방문 목록의 로컬 복사본을
업데이트합니다. DPU는 자신이 소유한 정점 에 해당하는 현재 프론티어의 정점
을 유지하고 나머지는 버립니다. DPU의 태스크릿은 (1) 이러한 정점을 동시에 통
과하고, (2) 이웃을 방문하고, (3) 이전에 방문하지 않은 경우 이웃을 다음 프론
티어에 추가합니다. BFS에 대한 이러한 접근 방식을 하향식 접근 방식이라고 합
니다 [256, 257]. Tasklet은 중요한 섹션(뮤텍스를 통해 구현됨)을 사용하여 데
이터 충돌 없이 다음 프론티어를 동시에 업데이트합니다. 각 반복이 끝나면 CPU
는 각 DPU가 생성한 다음 프론티어를 검색하고 합집합을 계산하여 완전한 다음
프론티어를 구성합니다. 반복이 끝나고 다음 프론티어가 비어 있을 때까지 반복
이 계속됩니다 .
17
4.9 다층 퍼셉트론 다층 퍼셉트론(MLP)
[258]은 입력, 은닉 및 출력의 세 가지 계층이 있는 피드포워드 인공 신경망 클래
스입니다.
MLP의 PIM 구현은 MLP 추론을 수행합니다. 각 레이어에서 가중치는 행렬
로 배열되고 입력은 벡터입니다. 각 레이어의 계산은 행렬‑벡터 곱셈입니다. 각 계
층의 구현은 GEMV 구현(4.2절)을 기반으로 합니다. 따라서 MLP의 각 계층에
서 DPU와 태스크릿 간의 워크로드 분포는 GEMV와 동일합니다. ReLU는 각
레이어 끝에 있는 활성화 함수입니다 . 레이어가 종료되면 호스트 CPU는 (1)
MRAM 뱅크에서 출력 벡터 청크를 검색하고 , (2) 완전한 벡터를 구성하고, (3)
이 벡터를 다음 레이어 의 입력으로 DPU에 공급하고 , (4) 다음 레이어의 가중치
행렬을 DPU로 전송합니다. 출력 레이어 끝에서 호스트 CPU는 출력 벡터 청크
를 검색하고 최종 출력 벡터를 구성합니다.
4.10 니들만‑분쉬
Needleman‑Wunsch(NW) [259] 는 전체 서열 정렬을 수행하는 생물정보
학 알고리즘입니다 . 즉, 두 생물학적 서열을 전체 길이에 걸쳐 비교하여 이들
서열의 최적 정렬을 찾습니다 . NW는 세 단계로 구성된 동적 프로그래밍 알고
리즘입니다 . (i) 2D 점수 행렬을 초기화 합니다 .
,
, 는 시퀀스의 길이입니다(즉, 각 시퀀스의 염기쌍 수( bps)). (ii) 행렬의 각
셀에 대한 점수를 계산하여 점수 행렬을 채웁니다 . 이는 이웃 셀(왼쪽, 위쪽 또는
왼쪽 위쪽 셀) 점수의 최대값에 불일치 시 페널티를 더한 것입니다 . (iii) 점수 행
렬의 오른쪽 하단에 있는 셀에서 다시 왼쪽 상단에 있는 셀까지의 경로를 표시하
여 최적의 정렬을 추적합니다. 두 서열 사이에는 하나 이상의 가능한 최적 정렬이
있을 수 있습니다 .
PIM 구현은 먼저 2D 점수 행렬의 위쪽 삼각형(왼쪽 위 부분)을 채운 다음
아래쪽 삼각형(오른쪽 아래 부분)을 채웁니다. 행렬은 큰 2D 블록으로 분할되
며 알고리즘은 큰 블록 세분성 (왼쪽 상단 대각선에서 오른쪽 하단 대각선까
지)으로 대각선을 반복합니다. 각 반복에서 2D 점수 행렬의 동일한 대각선에
속하는 모든 대형 블록은 DPU에 균등하게 분산되어 병렬로 계산됩니다. DPU
내부에서는 각각의 대형 2D 블록이 작은 2D 하위 블록으로 분할됩니다. 각
DPU의 태스크릿은 작은 하위 블록 세분성으로 대각선에서 작동합니다. 즉,
각 반복에서 DPU의 태스크릿은 한 대각선의 동일한 큰 블록에 속하는 서로
다른 작은 하위 블록을 동시에 계산합니다.
2D 점수 매트릭스의 각 대각선에 대해 호스트 CPU는 모든 DPU에서 생성된
대형 블록을 검색합니다. 그런 다음 각 큰 블록의 마지막 행과 마지막 열의 채워
진 셀을 다음 반복(즉, 다음 대각선)의 입력으로 사용합니다. 왜냐하면 이러한 셀
만이 다음 대각선 블록과 인접한 셀이기 때문입니다. 전체 2D 점수 행렬의 모든
대각선 큰 블록이 계산될 때까지 반복이 계속됩니다 . 호스트 CPU는 최종적으
로 결과 2D 점수 매트릭스를 사용하여 최적의 정렬을 추적합니다.
부록(섹션 9.2.1)에서는 완전한 문제의 계산과 가장 긴 대각선 스케일의 계산
이 DPU의 한 순위에 걸쳐 다르게 계산된다는 것을 보여주기 위해 NW에 대한
추가 실험 결과를 보여줍니다.
Machine Translated by Google
4.11 이미지 히스토그램 이미지 히스
토그램(HST) [260] 은 이미지의 히스토그램을 계산합니다. 즉, 입력 이미지에
서 가능한 각 픽셀 값의 발생 횟수를 계산 하고 집계된 발생 횟수를 일련의 빈
에 저장합니다.
우리는 이미지 히스토그램의 두 가지 PIM 구현인 짧은 (HST‑S) 및 긴(HST‑L)을
개발합니다.
HST‑S는 DPU에서 실행되는 태스크릿 전체에 입력 이미지 청크를 배포합
니다 . 각 태스크릿은 WRAM에 로컬 히스토그램을 생성합니다.
로컬 히스토그램이 생성되면 태스크릿은 장벽과 동기화되고 로컬 히스토그램은 병렬
방식으로 병합됩니다. 각 태스크릿에는 WRAM의 로컬 히스토그램이 있으므로 최대 히
스토그램 크기는 상대적으로 작습니다(예: 16개의 태스크릿을 실행할 때 256개의 32
비트 저장소 ).14
HST‑L은 DPU당 하나의 로컬 히스토그램만 WRAM에 저장되므로 크기가 WRAM
의 전체 양에 의해서만 제한되는 더 큰 히스토그램을 생성할 수 있습니다 . HST‑S와 마
찬가지로, HST‑L은 한 번에 하나의 태스크릿 만 히스토그램을 업데이트하도록 하기
위해 뮤텍스를 사용하여 WRAM의 히스토그램을 업데이트하는 태스크릿 전체에 입력
이미지 청크를 배포합니다.
HST‑S와 HST‑L은 모두 모든 DPU별 히스토그램을 호스트 CPU의 단일 최종 히
스토그램으로 병합합니다.
각 히스토그램 크기에 대해 UPMEM 기반 PIM 시스템에서 어떤 HST 버전이 선호
되는지 알아보기 위해 부록(섹션 9.2.2) 에서 다양한 히스토그램 크기에 대해 HST‑S
와 HST‑L을 비교합니다 .
4.12 감소
Reduction (RED) [261] 은 입력 배열 의 요소 합계를 계산합니다 .
PIM 감소 구현에는 두 단계가 있습니다. 첫 번째 단계에서는 DPU
내부의 각 태스크릿에 배열 청크가 할당됩니다. 태스크 릿은 청크의 모
든 값을 누적하고 로컬 축소 결과를 생성합니다. 두 번째 단계에서는
장벽 이후 단일 태스크릿이 첫 번째 단계의 모든 태스크릿의 부분 결
과를 줄입니다. 두 번째 단계가 끝나면 호스트 CPU는 감소 결과를 검
색합니다.
대안으로 두 번째 단계를 병렬 트리 축소 로 구현할 수 있습니다 [262,
263]. 우리는 서로 다른 DPU 내 동기화 프리미티브를 사용하는 두 가지 버전
의 병렬 트리 축소를 구현합니다 . 버전 중 하나는 트리의 한 수준에서 다음 수
준으로의 tasklet 간의 통신을 위해 핸드셰이크를 사용합니다. 그만큼
다른 버전은 트리 수준 사이에 장벽을 사용합니다. 부록 (9.2.3절)에서 단일 태스크
릿 구현을 두 가지 버전의 병렬 트리 축소와 비교합니다.
4.13 접두사 합계(스캔)
접두사 합계 또는 스캔(SCAN) [249] 은 배열 값의 접두사 합계를 계산하는 병렬 기
본 요소입니다. 우리는 배타적 스캔을 구현합니다. 출력의 ‑번째 요소에는 첫 번째 요소
부터 (‑1)번째 요소까지 입력 배열의 모든 요소 의 합계가 포함됩니다 .
우리는 스캔의 두 가지 PIM 버전인 Scan‑Scan‑Add(SCAN‑
SSA) [251, 264, 265] 및 스캔 감소 스캔(SCAN‑RSS) [251, 264,
14256 32비트 저장소는 (1) 히스토그램의 2제곱 크기를 가정하고 (2) 각 태스크릿이
입력 이미지 청크에 WRAM 버퍼를 할당한다는 점을 고려하여 16개의 태스크릿 에 대
한 최대 히스토그램 크기입니다 .
18
266]. 두 버전 모두 각 DPU에 입력 배열의 큰 부분을 할당합니다 .
SCAN‑SSA에는 세 단계가 있습니다. 먼저 각 DPU 내에서 로컬로 스캔 작
업을 계산합니다 . 둘째, 로컬 스캔의 마지막 요소를 호스트 CPU에 복사 하고
DPU 순서에 해당하는 위치의 벡터에 배치합니다 . 호스트 CPU는 이 벡터를
스캔하고 각 결과 값을 해당 DPU로 이동합니다. 셋째, 호스트 CPU에서 계산
된 값을 각 DPU의 로컬 스캔 출력의 모든 요소에 추가합니다. 넷째, 호스트
CPU는 MRAM 뱅크에서 스캔된 전체 어레이를 검색합니다.
SCAN‑RSS에도 세 단계가 있습니다. 먼저, 각 DPU에서 축소 연산을 계산합
니다 . 둘째, 감소 결과를 호스트 CPU에 복사하고, 호스트 CPU는 이를 스캔합니
다. 셋째, 호스트 CPU의 스캔 작업 결과 값을 해당 DPU로 이동합니다 . 여기서
태스크릿은 로컬 스캔( 호스트 CPU에서 오는 값 포함)을 수행합니다 . 넷째, 호스
트 CPU는 MRAM 뱅크에서 스캔된 전체 어레이를 검색합니다.
SCAN‑SSA에 비해 SCAN‑RSS의 장점은 SCAN‑RSS가
MRAM에 대한 액세스가 더 적게 필요합니다. 크기 배열의 경우 RSS에 , 주사‑
는 3 × + 1 액세스가 필요합니다. 즉, Reduce의 경우 읽기 및 1개의 쓰기, Scan의
경우 읽기 및 쓰기입니다. SCAN‑SSA에는 4 개의 액세스가 필요합니다.
Scan을 위해 읽고 쓰고, Add를 위해 읽고 씁니다.
SCAN‑RSS에 비해 SCAN‑SSA의 장점은 동기화가 덜 필요하다는 것입니다.
SCAN‑RSS의 축소 작업에는 장벽이 필요하지만 SCAN‑SSA의 추가 작업에
는 동기화가 필요하지 않습니다. 우리는 SCAN‑RSS가 MRAM에 대한 액세스
가 실행 시간을 지배하는 대규모 어레이에서 더 나은 성능을 발휘할 것으로 기
대하고, SCAN‑SSA는 동기화가 필요한 감소가 전체 계산의 더 큰 부분을 차
지하는 소규모 어레이에서 더 나은 성능을 발휘할 것으로 기대합니다 . 부록 섹
션 9.2.4에서 서로 다른 크기의 배열에 대한 두 가지 SCAN 구현을 비교합니
다.
4.14 행렬 전치 행렬 전치(TRNS) [267] 는
× 배열을 × 배열 로 변환합니다 . 우리는 전치된 배열이 원래 배열과 동일한
물리적 저장 위치를 차지하는 내부 전치에 중점을 둡니다 . 내부 전치(In‑place
transposition)는 순열이며, 이는 분리된 주기로 분해될 수 있습니다 [268].
간단한 병렬 구현은 전체 주기를 스레드에 할당할 수 있습니다. 그러나 이러한
간단한 구현에서는 (1) 직사각형 행렬에서 사이클 길이가 균일하지 않아 로드
불균형이 발생하고 (2) 작업이 단일 행렬 요소 에서 수행되므로(공간적 지역성
을 활용하지 않고) 메모리 액세스가 무작위입니다 . 따라서 효율적인 병렬화가
어렵습니다.
우리의 PIM 구현은 (1) 단일 요소가 아닌 매트릭스 요소의 타일 에서 작동하
여 공간적 지역성을 활용 하고 (2) 주기를 분할하여 작업 부하의 균형을 맞추는
효율적인 3단계 타일 접근 방식 [269, 270] 을 따릅니다. tasklet 전반에 걸쳐.
세 단계를 수행하기 위해 먼저 × 배열 의 차원을 인수분해합니다 . 여기서 = × 이
고
× 배열
′
′××
′ ′
= × .
첫 번째 단계는 타일 크기에서 작동합니다. 이 단계에서는 각 요소가 타일 크기인
′ 배열의 차원은 ′× × = ′× ′× × UPMEM 기
× 배열 의 전치를 수행합니다. 결과
반 PIM 시스템에서 호스트 CPU의 메인 메모리에서 해당 MRAM으로 입력 배열을 .
복사하는 크기가 지정된 CPU‑DPU 전송을 사용하여 이 단계를 수행합니다. 은행.
Machine Translated by Google
× ′ 수행합니다.
두 번째 단계에서는 × 타일의′전치를
각 DPU에서 하나의 태스크릿은 WRAM의 × 타일을 바꿉니다. 결과 배열에는 차원이 있습니다.
× ×× ′ . ′ 다.
세 번째 단계는 타일 크기에 대해 작동합니다. 이 단계에서는 각 요소가 크기 타일인 차원 배
′ × ,가능한 태스크릿은
열의 전치를 수행합니다. 결과 배열에는 차원이 있습니다 . 각 DPU에서 사용 ′
[271] 에 제시된 알고리즘을 사용하여 '× 배열(크기 요소 포함)의 전치에 협력합니다 . 동기화
′× × ′× . 를 위해 원자 명령을 사용하는 [ 271 ] 의 알고리즘과 달리 PIM 구현은 이
동된 타일을 추적하는 플래그 배열을 통해 태스크릿 동기화를 위해 뮤텍스를 사용합니다
( UPMEM ISA가 [ 271] 때문에 이 구현을 선택합니다. 213] 에는 원자 명령이 포함되지 않습니
다.
세 단계 후에 호스트 CPU는 전치된 값을 검색합니다.
MRAM 뱅크의 매트릭스.
5 주요 벤치마크 평가
이 섹션에서는 별도로 명시하지 않는 한 2,556‑DPU 시스템(섹션 2.1)에 대한 16
개의 PrIM 벤치마크를 평가합니다 . 우리의 평가는 공개적으로 무료로 사용할
수 있는 표 3에 제시된 데이터 세트를 사용합니다 [214]. 이러한 데이터 세트는
크고 WRAM에 맞지 않기 때문에 MRAM‑WRAM DMA 전송을 반복적으로 사
용해야 합니다.
우리가 제시하는 결과는 최고 성능의 전송 크기에 대한 것이며, 결과의 재현성을
용이하게 하기 위해 표 3에 포함시켰습니다 . 우리는 [214]의 모든 매개변수와 함
께 각 벤치마크를 실행하는 데 사용하는 명령줄을 제공합니다 .
먼저 성능 및 확장 결과를 제시합니다. (1) 1 DPU, (2) 1 순위
(1~64 DPU) 및 (3) 32 DPU에 대한 실험을 실행하여 2,556‑DPU
시스템 에서 16개 PrIM 벤치마크(섹션 5.1.1)에 대한 강력한 확장
3을 평가 합니다. 순위(256~2,048 DPU).
이러한 실험의 목표는 고정된 문제 크기에 대해 UPMEM 기반 PIM 시스템의
성능이 DPU 수에 따라 어떻게 확장되는지 평가하는 것입니다. 이상적인 강력
한 스케일링은 선형 스케일링입니다. 즉, 단일 DPU에서의 실행 에 비해 DPU
를 사용한 강력한 스케일링의 이상적인 속도 향상은 다음과 같습니다.
또한 1등급(1~64 DPU)의 16개 PrIM 벤치마크 (섹션 5.1.2) 에 대해 약한
스케일링4을 평가합니다 . 이 실험에서는 DPU당 고정된 문제 크기에 대해
UPMEM 기반 PIM 시스템의 성능이 DPU 수에 따라 어떻게 확장되는지 평가합
니다. 이상적인 약한 확장 시나리오에서는 DPU 수에 관계없이 실행 시간이 일정
하게 유지됩니다.
둘째, 2,556 DPU(최신 시스템) 및 640 DPU(이전 시스템)를 갖춘 두 가지 완전한 UPMEM
기반 PIM 시스템(표 1)의 성능 및 에너지 소비를 최신 Intel Xeon E3‑1240 CPU 와 비교합니
다 . 241] 및 최신 NVIDIA Titan V GPU [277](섹션 5.2).
섹션 6에서는 PIM 시스템에 대한 다양한 워크로드의 적합성에 대한 새로운 통찰력, 소프트웨
어 설계자를 위한 프로그래밍 권장 사항, 미래 PIM 시스템의 하드웨어 및 아키텍처 설계자를 위
한 제안 및 힌트를 제공합니다 .
5.1 성능 및 스케일링 결과 표 3의 데이터 세트를 사용하여 강
력한 스케일링 실험과 약한 스케일링 실험을 통해 모든 벤치마크의 성능을 평가합
니다. 섹션 5.1.1에서는 단일 DPU, 단일 순위( 1~64 DPU)에 대한 강력한 스케
일링 결과를 제시합니다. 4~32개 랭크 세트(256~2,048 DPU). 또한 DPU 간
동기화 비용도 평가합니다.
19
섹션 5.1.2에서는 1~64 DPU에 대한 전체 순위에 대한 약한 스케일링을 분석합니다. 분석에는
호스트 CPU를 통한 DPU 간 동기화 비용 과 CPU‑DPU 및 DPU‑ CPU 지연 시간이 포함됩니
5.1.1 강력한 스케일링 결과. 우리는 세 가지 다른 구성으로 강력한 확장을 평
가합니다 : (1) 하나의 DPU 내에 1‑16개의 태스크릿, (2)
한 랭크 내에 1~64개 DPU, (3) 4~32개 랭크. 단일 순위 및 다중 순위 내부 실
험의 경우 하나의 DPU에 대한 실험에서 가장 성능이 좋은 태스크릿 수를 사용합
니다 .
DPU 1개. 그림 12 는 단일 DPU의 16개 벤치마크에 대한 실행 시간 및 속도 향상 확장(태
스크릿 수 대비) 결과를 보여줍니다 .
속도 향상 결과(각 플롯의 오른쪽 y축) 는 DPU에 소요된 실행 시간 부분(즉, 그
림 12에서 각 막대의 "DPU" 부분 ) 에만 해당합니다 . 이 실험에서는 태스크릿
수를 1, 2, 4, 8, 16으로 설정했습니다. 벤치마크는 데이터 병렬 방식으로 사용 가
능한 태스크릿 간에 계산을 분산합니다. 데이터 세트 와 해당 크기는 표 3에 나
와 있습니다. 그림 12에 표시된 시간은 DPU의 실행 시간("DPU"), 호스트 CPU
를 통한 DPU 간 통신 시간("Inter‑DPU")으로 분류됩니다. , 입력 데이터가
CPU에서 DPU로 전송되는 시간("CPU‑DPU") 및 최종 결과가 DPU에서 CPU
로 전송되는 시간("DPU‑CPU")입니다.
우리는 그림 12에서 다음과 같은 다섯 가지 관찰을 수행합니다.
먼저 VA, GEMV, SpMV, SEL, UNI, TS, MLP, NW, HST‑S, RED, SCAN‑
SSA(스캔 커널), SCAN‑RSS(두 커널), TRNS( 2단계 커널) 에서는 가장 잘 수
행되는 태스크릿 수는 16개입니다. 이는 섹션 3.1.2의 관찰 내용과 일치합니다.
일반적 으로 파이프라인에서 최고의 성능을 얻으려면 11보다 큰 것이 좋은 선택
입니다 . 이 벤치마크는 8개까지 태스크릿 수를 두 배로 늘림에 따라 1.5 ~ 2.0
배 의 속도 향상으로 1~8개의 태스크릿으로의 양호한 확장을 보여줍니다. 8~16
개의 태스크릿에서 파이프라인 처리량이 포화 상태 로 인해 속도 향상은 1.2 ~
1.5배 입니다. 11개의 태스크릿. BS 및 BFS의 경우 16개의 태스크릿 도 최고의
성능을 제공합니다. 그러나 BS 및 BFS의 확장은 이 단락의 시작 부분에 나열된
커널보다 더 제한적입니다. 이 섹션의 뒷부분에서 설명합니다.
주요 관찰 10
11보다 큰 태스크릿 수는 DRAM 처리 장치의 파이프라인을 완전히 활용하므로 우
리가 테스트한 대부분의 실제 워크로드(16개 벤치마크의 19개 커널 중 16개 커널)
에 적합한 선택입니다.
둘째, 이러한 벤치마크 중 일부(VA, GEMV, SpMV, BS, TS, MLP, HST‑S,
TRNS(2단계))는 동기화 프리미티브를 사용하지 않는 반면, 다른 벤치마크(SEL,
UNI, NW, RED, SCAN‑SSA)는 (스캔 커널), SCAN‑RSS(두 커널 모두), 태스
크릿 간 동기화( 핸드셰이크 및/또는 장벽을 통해)가 가볍습니다.
셋째, BFS, HST‑L 및 TRNS(3단계)는 공유 데이터 구조(예: BFS의 출력 프
론티어, 로컬 DPU별 히스토그램)에 액세스할 때 경합을 유발하는 뮤텍스를 사용
하기 때문에 태스크릿 수를 늘릴 때 제한된 확장을 나타냅니다. HST‑L, TRNS
의 플래그 배열(3단계)). 16개의 tasklet을 사용하는 BFS에서는 큰 동기화 비용
을 보상할 수 있으므로 가장 높은 성능을 제공하는 반면 , HST‑L 및 TRNS(3단
계)에서는 가장 성능이 좋은 수의
Machine Translated by Google

표 3: 평가된 데이터 세트.

MRAM‑WRAM
강력한 확장성 데이터 세트 벤치마크 약한 확장 데이터세트 전송 크기

버지니아
1 DPU‑1 랭크: 250만 요소. (10MB) | 32등급: 1억 6천만 요소. (640MB) 2.5M 요소/DPU(10MB) 1024 × 1024바이트
GEMV 1 DPU‑1 랭크: 8192 × 1024 요소. (32MB) | 32등급: 163840 × 4096 요소. (2.56GB) bcsstk30 [273] (12MB) 2048 요소/DPU(8MB) bcsstk30 [273] 1024바이트

SpMV 64바이트
SEL 1 DPU‑1 랭크: 380만 요소. (30MB) | 32등급: 2억 4천만 요소. (1.9GB) 3.8M 요소/DPU(30MB) 1024바이트
유니 1 DPU‑1 랭크: 380만 요소. (30MB) | 32등급: 2억 4천만 요소. (1.9GB) 3.8M 요소/DPU(30MB) 1024바이트
학사 2M 엘레멘트. (16MB). 1 DPU‑1 순위: 쿼리 256,000개. (2MB) | 32개 순위: 1,600만 개의 쿼리. (128MB) 256요소 질문. 1 2M 엘레멘트. (16MB). 256K 쿼리./DPU(2MB). 8바이트
TS DPU‑1 등급: 512K 요소. (2MB) | 32등급: 32M 요소. (128MB) 512K 요소/DPU(2MB) rMat 256바이트
BFS loc‑gowalla [274] (22MB) 3개의 [275](DPU당 100K 정점 및 1.2 에지) 8바이트
MLP 완전 연결 레이어. 1 DPU‑1 랭크: 2K 뉴런(32MB) | 32개 등급: 160K 뉴어. (2.56GB) 3개의 완전히 연결된 레이어. 1K neur./DPU(4MB) 1024바이트
2560
북서쪽 1 DPU‑1 랭크: 2560bps(50MB), 대형/소형 하위 블록= 1 DPU‑1 랭크: 1536 # /2 | 32개 랭크: 64Kbps(32GB), l./s.=32/2 512bps/DPU(2MB), l./s.=512/2 8, 16, 32, 40바이트
HST‑S × 1024 입력 이미지 [276](6MB) | 32 랭크: 64 × 입력 이미지 1 DPU‑1 랭크: 1536 × 1024 입력 이미지 [276] 1536 × 1024 입력 이미지 [276]/DPU (6MB) 1536 × 1024바이트
HST‑L (6MB) | 32 랭크: 64 × 입력 이미지 1 DPU‑1 랭크: 6.3M elem. (50MB) | 32랭크: 4억엘렘. (3.1GB) 1024 입력 이미지 [276]/DPU (6MB) 1024바이트
빨간색 630만 요소/DPU(50MB) 1024바이트

SCAN‑SSA 1 DPU‑1 랭크: 380만 요소. (30MB) | 32등급: 2억 4천만 요소. (1.9GB) 3.8M 요소/DPU(30MB) 1024바이트
스캔‑RSS 1 DPU‑1 랭크: 380만 요소. (30MB) | 32등급: 2억 4천만 요소. (1.9GB) 3.8M 요소/DPU(30MB) 12288 1024바이트
TRNS 1 DPU‑1 랭크: 12288 × 16 × 64 × 8(768MB) | 32랭크: 12288 × 16 × 2048 × 8(24GB) × 16 × 1 × 8/DPU(12MB) 128, 1024바이트

tasklet은 8을 초과하는 높은 동기화 오버헤드로 인해 8입니다. 다음에 설명된 대로 ′ 요소의 × 데이터 전송을 발행하여
태스크릿. 섹션 4.14. 실험에서는 작은 값( = 8)을 사용하므로,
주요 관찰 11
표 3에 표시된 대로), 지속적인 CPU‑DPU 대역폭은
최대 CPU‑DPU 대역폭에서(지속적인 CPU‑DPU 참조)
전체에 걸쳐 내부 DPU 동기화를 집중적으로 사용 그림 10a의 다양한 전송 크기에 대한 대역폭)
태스크릿(예: 뮤텍스, 장벽, 핸드셰이크)은 주요 관찰 13
확장성을 제한하여 때로는 최고의 성능을 발휘 하는 태스크릿
수가 11개 미만이 되는 경우도 있습니다. 호스트와 대용량 데이터 청크 전송
입력 데이터 및 출력 결과에는 CPU가 선호됩니다.
더 높은 지속 CPU‑DPU/DPU‑CPU 대역폭.
넷째, SCAN‑SSA(커널 추가)는
태스크릿 수를 8개까지 두 배로 늘리면 1.5× 및 2.0× 입니다. 방법‑
이 단계에도 불구하고 8개에서 16개 태스크릿으로 속도가 향상되지는 않습니다.
SCAN‑SSA 벤치마크에서는 동기화를 사용하지 않습니다. 1등급(1‑64 DPU). 우리는 1에서 1까지의 강력한 스케일링을 평가합니다.
기초 요소. STREAM ADD에서도 동일한 동작이 관찰됩니다. DPU 64개. 입력 크기는 우리가 넣을 수 있는 데이터 세트 크기입니다.
그림 7의 마이크로벤치마크, 즉 성능 포화가 발생함 단일 DPU(표 3 참조) 특히 CPU‑DPU 전송을 검토합니다.
파이프라인을 완전히 활용하는 데 필요한 11개의 태스크릿 이전. 섹션 3.2.2 DPU‑CPU 전송 시간이 어떻게 변화하는지 평가하기 위해
에서 설명했듯이 그 이유는 STREAM ADD와 DPU 수를 늘립니다. 그림 13은 실행 시간을 보여줍니다.
SCAN‑SSA(커널 추가)는 계산 집약적인 커널이 아닙니다. 1, 4, 16, 64에 대한 속도 향상 확장(DPU 수 대비) 결과
액세스된 입력 요소당 하나의 정수 추가만 수행합니다. DPU. 속도 향상 결과(각 플롯의 오른쪽 y축)는 다음과 같습니다.
MRAM에서. 결과적으로 전체 대기 시간은 DPU(예: "DPU")에 소비된 실행 시간 부분만
파이프라인 대기 시간을 숨기는 MRAM 액세스 대기 시간(따라서 그림 13의 각 막대 부분). 실행 시간 분석
완전히 수행하는 데 필요한 11개 미만의 태스크릿에서 성능이 포화됩니다. 단일 DPU 결과에 대한 그림 12의 결과와 동일합니다.
파이프라인을 활용하세요). 동일한 이유는 BS가 8개에서 16개 태스크릿으로 속도 향상을 우리는 그림 13에서 다음과 같은 7가지 관찰을 수행합니다.
거의 얻지 못함(단 3%)을 설명합니다. 첫째, DPU 성능 확장이 선형적이라는 것을 관찰했습니다.
입력 요소당 하나의 비교만 가능합니다. DPU 수(즉, DPU의 실행 시간은 다음과 같이 선형적으로 감소합니다.
VA, GEMV, SpMV, SEL, UNI의 경우 DPU 수를 늘립니다.
주요 관찰 12
BS, TS, MLP, HST‑S, HST‑L, RED, SCAN‑SSA(두 커널), SCAN‑ RSS(두
커널) 및 TRNS(두 커널)(두 커널 사이의 속도 향상)
대부분의 실제 워크로드는 DRAM 처리 장치(모든 커널)의 컴퓨팅 바인딩 영역에 있
DPU 수를 4개 늘리면 3.1배 및 4.0배 ). 로서
습니다.
결과적으로 이러한 벤치마크에 대해 DPU 수가 1에서 64로 증가합니다.
SCAN‑SSA(커널 추가) 제외), 즉 파이프라인 대기 시간
37×(SpMV)에서 64×(TS, TRNS) 사이의 속도 향상을 생성합니다.
MRAM 액세스 대기 시간을 지배합니다.
둘째, DPU 성능 확장은 두 벤치마크(BFS, NW)에 대해 선형적이지 않습
니다. 이에 대한 DPU 수를 1에서 64로 늘립니다.
다섯째, CPU‑DPU 전송에 소요되는 시간과 두 벤치마크는 8.3배 (BFS)에서 17.2배 사이의 속도 향상을 제공합니다.
DPU‑CPU 전송은 소요 시간에 비해 상대적으로 낮습니다. (NW). BFS의 경우 DPU 간 로드 불균형으로 인해 속도 향상은 선형적이지 않습니다 ( DPU 수
대부분의 벤치마크에서 DPU 실행에서는 CPU‑DPU가 를 4씩 늘릴 때 1.7‑2.7× ).
TRNS에서는 전송 시간이 매우 높습니다. TRNS의 CPU‑DPU 전송 loc‑gowalla 그래프의 불규칙한 토폴로지에 의해 생성됩니다 [274].
행렬 전치 알고리즘의 1단계를 수행합니다. [269, 270] NW에서는 곱할 때 속도 향상이 2.2배 에서 3.3배 사이입니다.

20
Machine Translated by Google

DPU‑CPU DPU‑CPU DPU‑CPU DPU‑CPU

1200 CPU‑DPU
14 1600 CPU‑DPU
12 10000 12 1400 8
CPU‑DPU CPU‑DPU
DPU 간
1400 DPU 간 9000 DPU 간 DPU 간 7
1000 DPU
12 DPU 10 DPU 10 1200
8000 DPU
속도를 올리다 1200 속도를 올리다 속도를 올리다 속도를 올리다 6
10 7000 1000
800 8 8
1000 6000 5
8 800
600 800 6 5000 6 4
6 600

다
리
올
를
도
속

다
리
올
를
도
속

다
리
올
를
도
속

다
리
올
를
도
속
600 4000 삼
400 4 4
4 3000 400
400 2
간(
시
행
실

간(
시
행
실

간(
시
행
실

간(
시
행
실
)sm

)sm

)sm

)sm
2000
200 2 2 2 200
200 1000 1

0 0 0 0 0 0 0 0
1

1
2

2
8

8
4

4
61

61

61

61
버지니아 GEMV SpMV SEL
DPU당 #tasklet DPU당 #tasklet DPU당 #tasklet DPU당 #tasklet
DPU‑CPU DPU‑CPU DPU‑CPU DPU‑CPU
1200 8 14000 CPU‑DPU
6 140000 CPU‑DPU
12 4000 CPU‑DPU
3.0
CPU‑DPU
DPU 간 DPU 간 DPU 간
DPU 간 7 12000 120000 3500
1000 DPU
DPU 5 DPU 10 DPU 2.5
속도를 올리다 6 속도를 올리다 속도를 올리다 3000 속도를 올리다
10000 100000
800 4 8 2.0
5 2500
8000 80000
600 4 삼 6 2000 1.5
6000 60000
다
리
올
를
도
속

다
리
올
를
도
속

다
리
올
를
도
속

다
리
올
를
도
속
삼 1500
400 2 4 1.0
4000 40000
2 1000
간(
시
행
실

간(
시
행
실

간(
시
행
실

간(
시
행
실
)sm

)sm

)sm

)sm
200 2000 1 20000 2 0.5
1 500

0 0 0 0 0 0 0 0.0
1

1
2

2
8

8
4

4
61

61

61

61
유니 학사 TS BFS
DPU당 #tasklet DPU당 #tasklet DPU당 #tasklet DPU당 #tasklet
DPU‑CPU DPU‑CPU DPU‑CPU DPU‑CPU
1600 12 250 7 1600 12 1800 6
CPU‑DPU CPU‑DPU CPU‑DPU CPU‑DPU

1400 DPU 간 DPU 간

6 1400 DPU 간 1600 DPU 간
DPU 10 DPU DPU 10 DPU 5
200 1400
1200 속도를 올리다 속도를 올리다 1200 속도를 올리다 속도를 올리다
5
8 8 1200 4
1000 150 1000
4 1000
800 6 800 6 삼
800
다
리
올
를
도
속

다
리
올
를
도
속

다
리
올
를
도
속

다
리
올
를
도
속
삼
600 100 600
4 4 600 2
2
400 400
간(
시
행
실

간(
시
행
실

간(
시
행
실

간(
시
행
실
400
)sm

)sm

)sm

)sm
50
2 1 2 1
200 200 200
0 0 0 0 0 0 0 0
1
2

8
4
1

1
2

2
8

8
4

4
61

61

61

61
MLP 북서쪽 HST‑S HST‑L
DPU당 #tasklet DPU당 #tasklet DPU당 #tasklet DPU당 #tasklet
DPU‑CPU DPU‑CPU CPU‑DPU DPU‑CPU CPU‑DPU DPU‑CPU CPU‑DPU(1단계)
2500 CPU‑DPU
14 DPU 간 DPU(스캔) Inter‑DPU DPU(스캔) DPU 간 DPU(3단계)
속도 향상(스캔) DPU(감소) 2500 속도 향상(스캔) DPU(2단계) 속도 향상(3단계)
DPU 간 DPU(추가)
DPU
12 2500
속도 향상(추가) 7 속도
상(빨간색)
향 12 16000
속도 향상(2단계) 12
2000
속도를 올리다
10 6 14000
2000 2000 10 10
5 12000
1500 8 8 8
1500 1500 10000
4
6
다
리
올
를
도
속

1000 6 8000 6
다
리
올
를
도
속

다
리
올
를
도
속

다
리
올
를
도
속
삼
1000 1000 6000
4 4 4
2
간(
시
행
실

4000
)sm

500 500 500

간(
시
행
실

간(
시
행
실

간(
시
행
실

2 2 2
)sm

)sm

)sm

1 2000
0 0 0 0 0 0 0 0
1

1
2

2
8

8
4

4
61

61

61

61

빨간색 스캔‑SSA 스캔‑RSS TRNS

DPU당 #tasklet DPU당 #tasklet DPU당 #tasklet DPU당 #tasklet

그림 12: 하나의 DPU(왼쪽 y축)에 있는 1, 2, 4, 8 및 16개 태스크릿에 대한 16개 벤치마크의 실행 시간(ms) 및 속도 향상(DPU에 소비된 실행 시간 부분만 고려) 1
개의 태스크릿(오른쪽 y축)의 성능으로 정규화된 더 많은 태스크릿.

DPU는 4로 계산됩니다. 이 벤치마크에서 각 반복의 병렬화 요소 (즉, 활성 DPU 사용 가능한 모든 DPU를 사용할 만큼 블록이 충분합니다. 결과적으로 NW의
수)는 처리되는 2D 점수 행렬의 대각선 크기와 대각선의 대형 2D 블록 수 에 따 확장성은 준선형적입니다.
라 달라집니다. . DPU 수를 4만큼 늘리면 더 작은 대각선의 병렬화 인자 는 낮고 셋째, DPU 간 동기화의 오버헤드( 그림 13 각 막대의 "DPU 간" 부분으로
(즉, 이러한 대각선의 블록 수와 동일) 더 큰 대각선에서는 최대 4배 까지만 증가 표시됨)는 14개 벤치마크(VA, GEMV, SpMV, SEL, UNI, BS)에서 낮습니다. ,
합니다 (즉, TS, HST‑ S, HST‑L, RED, SCAN‑SSA, SCAN‑RSS, TRNS). 결과적으로 이
러한 벤치마크는 DPU 수를 늘릴 때(DPU 간 동기화 포함) 더 높은 성능을 달성
합니다.

21
Machine Translated by Google

DPU‑CPU DPU‑CPU DPU‑CPU DPU‑CPU

300 CPU‑DPU
60 700 CPU‑DPU
70 1000 40 450 CPU‑DPU
70
CPU‑DPU
DPU 간 DPU 간 900 DPU 간 35 400 DPU 간
250 DPU 50 600 DPU
60 DPU DPU
60
800 350
속도를 올리다 속도를 올리다 속도를 올리다 30 속도를 올리다
500 50 700 50
200 40 300
600 25
400 40 250 40
150 30 500 20
200

다
리
올
를
도
속

다
리
올
를
도
속

다
리
올
를
도
속

다
리
올
를
도
속
300 30 400 30
15
100 20 150
200 20 300 20
10
간(
시
행
실

간(
시
행
실

간(
시
행
실

간(
시
행
실
100
)sm

)sm

)sm

)sm
200
50 10 100 10 10
100 5 50
0 0 0 0 0 0 0 0
1

1
4

4
61

61

61

61
46

46

46

46
버지니아 GEMV SpMV SEL
#DPU #DPU #DPU #DPU
DPU‑CPU DPU‑CPU DPU‑CPU DPU‑CPU
400 CPU‑DPU
70 2500 70 12000 70 1400 CPU‑DPU
9
CPU‑DPU CPU‑DPU
DPU 간 DPU 간 DPU 간 DPU 간 8
350 60 60 60 1200
DPU
2000 DPU 10000 DPU DPU
7
300 속도를 올리다
속도를 올리다 속도를 올리다 속도를 올리다
50 50 50 1000
8000 6
250 1500
40 40 40 800 5
200 6000
4
다
리
올
를
도
속

다
리
올
를
도
속

다
리
올
를
도
속

다
리
올
를
도
속
30 1000 30 30 600
150
4000 삼
20 20 20 400
100
간(
시
행
실

간(
시
행
실

간(
시
행
실

간(
시
행
실
2
)sm

)sm

)sm

)sm
500 2000
50 10 10 10 200
1
0 0 0 0 0 0 0 0
1

1
4

4
61

61

61

61
46

46

46

46
유니 학사 TS BFS
#DPU #DPU #DPU #DPU
DPU‑CPU DPU‑CPU DPU‑CPU DPU‑CPU
1400 CPU‑DPU
70 2500 CPU‑DPU
20 160 60 500 70
CPU‑DPU CPU‑DPU
DPU 간 DPU 간 18 140 DPU 간 450 DPU 간
1200 DPU 60 DPU DPU 50 DPU 60
속도를 올리다
2000 속도를 올리다
16 400
120 속도를 올리다 속도를 올리다
1000 50 14 350 50
40
1500 12 100 300
800 40 40
10 80 30 250
다
리
올
를
도
속

다
리
올
를
도
속

다
리
올
를
도
속

다
리
올
를
도
속
600 30 1000 8 200 30
60
6 20 150
400 20 20
40
간(
시
행
실

간(
시
행
실

간(
시
행
실

간(
시
행
실
)sm

)sm

)sm

)sm
500 4 100
200 10 10 10
2 20 50
0 0 0 0 0 0 0 0
1
4
1

1
4

4
61

61

61

61
46

46

46

46
MLP 북서쪽 HST‑S HST‑L
#DPU #DPU #DPU #DPU
DPU‑CPU DPU‑CPU CPU‑DPU DPU‑CPU CPU‑DPU DPU‑CPU CPU‑DPU(1단계)
350 70 DPU 간 DPU(스캔) DPU 간 DPU(스캔) DPU 간 DPU(3단계)
CPU‑DPU
DPU(추가) 속도 향상(스캔) DPU(감소) 속도 향상(스캔) DPU(2단계) 속도 향상(3단계)
DPU 간 800 70
300 60 속도 향상(추가) 7.E+02 속
도 향상(빨간색) 70 8.E+05 속
도 향상(2단계) 70
DPU
700 60 7.E+05
250
속도를 올리다
50 6.E+02 60 60
600 6.E+05
50 5.E+02 50 50
200 40 500 5.E+05
40 4.E+02 40 40
400 4.E+05
다
리
올
를
도
속

150 30
30
다
리
올
를
도
속

3.E+02 30 30
다
리
올
를
도
속

다
리
올
를
도
속
300 3.E+05
100 20
20 2.E+02 20 20
간(
시
행
실

200 2.E+05
)sm

간(
시
행
실

간(
시
행
실

간(
시
행
실
)sm

)sm

)sm

50 10 100 10 1.E+02 10 10
1.E+05
0 0 0 0 0.E+00 0 0.E+00 0
1

1
4

4
61

61

61

61
46

46

46

46

빨간색 스캔‑SSA 스캔‑RSS TRNS

#DPU #DPU #DPU #DPU

그림 13: 한 등급(1, 4, 16, 64개 DPU, 강력한 스케일링3 사용)에서 16개 벤치마크의 실행 시간(ms) (왼쪽 y축) 및 속도 향상(DPU에 소비된 실
행 시간 부분만 고려) )는 DPU 1개(오른쪽 y축)의 성능으로 정규화된 더 많은 DPU에 의해 제공됩니다. DPU 내부에서는 그림 12에서 가장 성능
이 좋은 태스크릿 수를 사용합니다.

시간). VA, GEMV, SpMV, BS, TS 및 TRNS 에는 DPU 간 동기화가 없습니다 . SCAN‑RSS는 DPU 실행 시간의 각각 53%, 91%, 48%, 42%, 17%를 차
HST‑S 및 HST‑L(최종 히스토그램 축소용)에는 DPU 간 동기화가 있지만 오버 지합니다 (그림 13에는 표시되지 않음). 그럼에도 불구하고 우리는 SEL, UNI,
헤드는 미미합니다. DPU 간 동기화 시간은 SEL, UNI, RED(최종 결과 병합용) RED에 대해 64개의 DPU를 사용하여 여전히 최고의 성능( DPU에 소요되는
와 SCAN‑SSA 및 SCAN‑RSS(호스트의 중간 스캔 단계용)에서 두드러집니다. 실행 시간 부분, 즉 "DPU" 및 DPU 간 동기화, 즉 "Inter‑DPU" 포함)을 얻
64개 DPU의 경우 SEL, UNI, RED, SCAN‑SSA 및 습니다. , SCAN‑SSA 및 SCAN‑RSS.

22
Machine Translated by Google
넷째, BFS, MLP 및 NW에 대한 DPU 간 동기화의 오버헤드가 상당히 높다
는 것을 관찰했습니다 . MLP에서는 DPU 수가 증가함에 따라 DPU 간 동기화
오버헤드(가중치 행렬 및 각 레이어에 대한 입력 벡터 의 분포로 인해 )가 감소합
니다 . 그 이유는 가중치 행렬의 분포 (즉, 할당된 행렬 행을 해당 DPU에 복사)
가 병렬 CPU‑DPU 전송을 활용하는 반면 입력 벡터 전송에 따른 오버헤드는 무
시할 수 있기 때문입니다. 그러나 BFS와 NW에서는 추세가 다릅니다. 64개 DPU
의 전체 성능( DPU 실행 시간 부분, 즉 "DPU" 및 DPU 간 동기화, 즉 "Inter‑
DPU" 포함)은 16개 DPU보다 각각 5% 및 17% 더 높습니다. 각각 BFS와 NW
에 대해.
BFS의 이유는 각 반복 후에 CPU가 모든 DPU에서 다음 프론티어의 합집합
을 순차적으로 계산하고 이를 DPU 전체에 재분배해야 하기 때문입니다. 따라
서 DPU 간 동기화 비용은 DPU 수에 따라 선형적으로 증가합니다. NW에서
도 비슷한 이유로 DPU 간 동기화 오버헤드가 상당합니다 . 2D 점수 행렬의 각
대각선에 대해 호스트 CPU는 (1) 모든 DPU에서 생성된 하위 블록의 결과를
검색하고, (2) 각 하위 블록의 마지막 행과 마지막 열의 셀을 보냅니다.
다음 대각선에 대한 입력으로 사용됩니다(다음 반복에서 처리됨).
다섯째, VA, GEMV, TS, MLP, HST‑S, HST‑L, RED, SCAN‑SSA, SCAN‑
RSS 및 TRNS에 대해 CPU‑DPU 전송 및 DPU‑CPU 전송 시간이 감소하는 것
을 관찰했습니다. 1등급에 대한 강력한 확장 실험의 DPU 수입니다 . 이 벤치마크
에서는 호스트 CPU의 메인 메모리와 MRAM 뱅크 간의 병렬 CPU‑DPU 및
DPU‑CPU 전송을 사용합니다 .
여섯째, BS와 NW가 병렬 전송을 사용하더라도 DPU 수가 증가함에 따
라 BS와 NW의 CPU‑DPU 및 DPU‑CPU 전송 시간은 감소하지 않습니다 .
BS는 사용 가능한 DPU 전체에 정렬된 배열에서 검색할 값을 배포 하지만 정
렬된 배열은 각 DPU에 복제됩니다. 결과적으로 총 CPU‑DPU 시간은 DPU 수
에 따라 증가합니다. NW는 각 반복마다 대각선을 처리합니다 . 더 짧은 대각
선의 경우 알고리즘은 사용 가능한 모든 DPU를 사용할 필요가 없습니다. 따
라서 사용 가능한 DPU가 더 많다고 해서 항상 CPU‑DPU 및 DPU‑CPU 전
송의 병렬 처리가 더 많아지는 것은 아닙니다 .
일곱째, 나머지 벤치마크(SpMV, SEL, UNI, BFS)는 병렬 전송을 사용하여
입력 데이터를 복사하거나 결과를 검색할 수 없습니다.
SEL 및 UNI에서는 결과 검색 에 병렬 전송을 사용할 수 없기 때문에 DPU 수를
늘리면 DPU‑CPU 전송 시간이 늘어납니다 . 이 두 벤치마크에서는 입력 배열 의
요소 값에 따라 각 DPU의 출력 크기가 다를 수 있습니다. SpMV와 BFS 는 각
DPU 에 할당된 입력의 크기가 다를 수 있기 때문에 병렬 CPU‑DPU 및 DPU‑
CPU 전송을 사용할 수 없습니다. BFS). 결과적으로 DPU 수를 늘려도 SpMV
및 BFS에서는 CPU‑DPU 및 DPU‑CPU 전송 시간이 감소하지 않는 것으로 나
타났습니다 .
프로그래밍 권장 사항 5
랭크 내에서 병렬 CPU‑DPU/DPU‑CPU 전송
전송된 모든 버퍼가 동일한 크기일 때 실제 작업 부하에는 UPMEM DRAM 처리 장치
의 3개를 권장합니다 .
23
32개 랭크(256~2,048 DPU). 우리는 4, 8, 16, 32 등급 으로 강력한 스케
일링을 평가합니다 . 입력 크기는 표 3에 표시된 대로 4개 순위(예: 256 DPU)
에 맞출 수 있는 최대 데이터 세트 크기입니다.
우리는 CPU‑DPU 및 DPU‑CPU 전송 시간을 포함하지 않습니다.
성능 분석은 섹션 3.4에서 언급한 것처럼 이러한 전송이 순위 전체에 걸쳐 동시에
이루어지지 않기 때문입니다 . 그림 14는 4, 8, 16, 32개 랭크에 해당하는 256,
512, 1,024, 2,048 DPU 에 대한 실행 시간 및 속도 향상 확장(DPU 수 대비)
결과를 보여줍니다 . 속도 향상 결과(각 플롯의 오른쪽 y축)는 DPU에 소요된 실
행 시간 부분(즉, 그림 14에서 각 막대의 "DPU" 부분)에만 해당합니다.
우리는 그림 14에서 다음과 같은 관찰을 합니다.
첫째, 한 순위에 대한 실험에서와 같이 DPU의 실행 시간(즉, 그림 14의 각 막
대의 "DPU" 부분)이 DPU 수(즉, 두 배로 증가하면 ~2×) 에 따라 선형적으로
감소하는 것을 관찰합니다. VA, GEMV, SEL, UNI, BS, TS, MLP, HST‑S,
HST‑L, RED, SCAN‑SSA(두 커널 모두), SCAN‑ 의 경우 DPU 수 및
256~2,048 DPU에서 ~8× ) RSS(두 커널) 및 TRNS(두 커널). SCAN‑SSA(스
캔) 및 SCAN‑RSS(스캔)의 경우 DPU를 256개에서 2,048개로 확장하면 속도
가 8배 이상 향상되는 것을 확인할 수 있습니다 . 그 이유는 더 많은 DPU에 입력
배열을 배포하면 태스크릿(예: 스캔의 핸드셰이크) 전체 에 걸친 동기화 양이 줄
어들기 때문입니다 . 그러나 단점은 아래에서 설명하는 것처럼 DPU 간 통신 비용
이 증가한다는 것입니다.
둘째, DPU 성능 확장(즉, 그림 14에서 각 막대의 "DPU" 부분 )은 SpMV,
BFS 및 NW에 대해 부분선형입니다. SpMV 및 BFS의 경우 그래프와 희소 행렬
의 불규칙한 특성으로 인해 DPU 전체에 로드 불균형이 발생합니다 . NW의 경
우 DPU 수를 두 배로 늘리면 (256 DPU에서 512 DPU로 1.60배 , 512 DPU에
서 1,024 DPU로 1.25배 ) 속도가 약간 향상되고 1,024 DPU에서 2,048 DPU
로 속도 향상이 거의 없습니다(단 8%). 위에서 설명한 것처럼 NW는 모든 반복
에서 모든 DPU를 사용하지 않고 각 반복에서 처리되는 대각선에 필요한 개수만
사용합니다. 결과적으로 DPU 수를 두 배로 늘려도 동일한 속도로 DPU에 소요
되는 실행 시간은 줄어들지 않습니다 .
주요 관찰 14
DPU(DRAM 처리 장치) 전반에 걸친 로드 밸런싱은 사용 가능한 모든 DPU가 사용될
때(강력한 확장 실험에서 관찰된 바와 같이) 주어진 문제 크기에 대해 DPU에 소요되
는 실행 시간을 선형적으로 감소시킵니다 .
셋째, DPU 간 동기화( 그림 14의 각 막대의 "DPU 간" 부분으로 표시됨)
는 12개 벤치마크(VA, GEMV, SpMV, SEL, UNI, BS, TS, HST‑S, HST‑L,
RED 및 TRNS). VA, GEMV, SpMV, BS, TS 및 TRNS에는 DPU 간 동기화가
필요하지 않습니다. SEL, UNI, HST‑S, HST‑L 및 RED의 경우 실행이 끝날 때
최종 결과를 병합하는 데만 사용되므로 DPU 간 동기화에는 DPU‑CPU 전송만
포함됩니다. 병합할 부분 결과의 양이 증가하므로 DPU 수에 따라 DPU 간 동기
화 오버헤드 가 증가합니다 . 그러나 DPU 간 동기화 비용은 적으며 DPU 수가 많
을수록 전체 성능이 향상됩니다.
Machine Translated by Google

90 8 160 8 1000 7 160 9

DPU 간 DPU 간 DPU 간 DPU 간
80 7 140 7 900 140 8
DPU DPU DPU 6 DPU
70 속도를 올리다 속도를 올리다
800 속도를 올리다 7
6 120 6 속도를 올리다 120
700 5
60 6
5 100 5 600 100
50 4 5
4 80 4 500 80

다
리
올
를
도
속

다
리
올
를
도
속

다
리
올
를
도
속

다
리
올
를
도
속
40 삼
4
삼 60 삼
400 60
30 삼
300 2
2 40 2 40
간(
시
행
실

간(
시
행
실

간(
시
행
실

간(
시
행
실
)s m

)s m

)s m

)s m
20 200 2
1 20 1 1 20
10 100 1
0 0 0 0 0 0 0 0
652

652

652

652
215

215

215

215
GEMV SEL
4201

4201

4201

4201
840년
2

840년
2

840년
2

840년
2
버지니아
SpMV

#DPU #DPU #DPU #DPU

120 8 700 DPU 간 9 3000 9 9000 삼

DPU 간 DPU 간 DPU 간
DPU
7 8 8 8000
100
DPU 600 속도를 올리다 2500
DPU DPU
속도를 올리다 7 속도를 올리다 7 7000 2
6 속도를 올리다
500
80 6 2000 6 6000
5 2
400 5 5 5000
60 4 1500
다
리
올
를
도
속

다
리
올
를
도
속

다
리
올
를
도
속

다
리
올
를
도
속
300 4 4 4000
삼
1
40 삼 1000 삼 3000
200
2
간(
시
행
실

간(
시
행
실

간(
시
행
실

간(
시
행
실
)sm

)sm

)sm

)sm
2 2 2000 1
20 100 500
1 1000
0 0 0 10 0 10 0 0
652

652

652

652
215

215

215

215
TS BFS
4201

4201

4201

4201
840년
2

840년
2

840년
2

840년
2
유니 학사

#DPU #DPU #DPU #DPU

1200 8 100000 2.5 40 8 120 9
DPU 간 DPU 간
7 90000 35 7 8
DPU DPU
1000 100
80000 2.0 속도를 올리다 속도를 올리다 7
6 30 6
70000
800 80 6
5 25 5
DPU 간 60000 1.5
5
600 DPU 4 50000 20 4 60
다
리
올
를
도
속

다
리
올
를
도
속

다
리
올
를
도
속

다
리
올
를
도
속
속도를 올리다
4
삼
40000 DPU 간 1.0 15 삼
400 DPU 40 삼
30000
간(
시
행
실

간(
시
행
실

간(
시
행
실

간(
시
행
실
)sm

)sm

)sm

)sm
2 속도를 올리다 10 2 2
20000 0.5
200 20
1 10000 5 1 1

0 0 0 0.0 0 0 0 0
652

652

652

652
215

215

215

215
MLP 북서쪽 HST‑L
4201

4201

4201

4201
840년
2

840년
2

840년
2

840년
2
HST‑S

#DPU #DPU #DPU #DPU

DPU 간 DPU 간 DPU 간
180 8 400 12 350 DPU(스캔)
12 3500 DPU(3단계)
9
DPU(스캔)
DPU 간
DPU(추가) DPU(감소) DPU(2단계)
160 DPU 7 350 8
속도 향상(스캔) 10 300 속도 향상(스캔) 10 3000 속도 향상(3단계)
140 속도를 올리다
6 속도 향상(추가) 속도 향상(빨간색) 속도 향상(2단계) 7
300
250 2500
120 8 8 6
5 250
100 200 2000 5
4 200 6 6
다
리
올
를
도
속

다
리
올
를
도
속

다
리
올
를
도
속

다
리
올
를
도
속
80 150 1500 4
삼 150
60 4 4 삼
100 1000
간(
시
행
실

간(
시
행
실

간(
시
행
실

간(
시
행
실
)sm

)sm

)sm

)sm

2 100
40 2
2 2
20 1 50 50 500
1
0 0 0 0 0 0 0 0
652

215

652

652

652
215

215

215

빨간색
4201

840년
2

TRNS
4201

4201

4201
840년
2

840년
2

840년
2

스캔‑SSA 스캔‑RSS

#DPU #DPU #DPU #DPU

그림 14: 4, 8, 16, 32 순위(256, 512, 1,024, 2,048 DPU, 강력한 스케일링3 사용)에서 16개 벤치마크의 실행 시간(ms)( 왼쪽 y축) 및 속도 향상(부분만 고
려) DPU에 소요된 실행 시간)은 4개 등급(256개 DPU)의 성능으로 정규화된 더 많은 DPU에 의해 제공됩니다(오른쪽 y축). DPU 내부에서는 그림 12에서 가
장 성능이 좋은 태스크릿 수를 사용합니다.

주요 관찰 15 넷째, DPU 간 동기화는 보다 복잡한 패턴(CPU‑DPU 및 DPU‑CPU 전

송 모두 포함)이 필요할 때 상당한 오버헤드를 부과합니다. 우리는 5개 벤치마
호스트 CPU의 DRAM 처리 장치에서 부분 결과를 병합하는 크 (BFS, MLP, NW, SCAN‑SSA 및 SCAN‑RSS) 에서 이를 관찰했습니다 .
오버헤드는 이를 필요로 하는 모든 PrIM 벤치마크 에서 허용 NW와 MLP의 경우 DPU 간 동기화 시간이 상당히 길다는 것을 알 수 있습니
할 수 있습니다. 다.

24
Machine Translated by Google
DPU 시간보다 높습니다. 이러한 결과를 그림 13의 결과와 비교하면 이러한
벤치마크의 전체 성능은 둘 이상의 순위를 사용할 때 DPU 간 동기화로 인해
큰 부담을 받는다는 결론을 내립니다. SCAN‑SSA 및 SCAN‑RSS 는 CPU에
서 보다 복잡한 중간 단계를 수행합니다 . (1) CPU는 DPU(DPU‑CPU를 통
해)의 첫 번째 커널(SCAN‑SSA에서 스캔, SCAN‑RSS에서 감소)의 부분 결
과를 수집합니다. (2) CPU는 스캔 작업을 수행하고, (3) CPU는 두 번째 커널
(Add in SCAN‑SSA, Scan in SCAN‑RSS)에서 사용할 값을 각 DPU에 반
환합니다( CPU 를 통해). ‑DPU 전송). "Inter‑DPU"가 1,024에서 2,048
DPU로 크게 증가한 것은 듀얼 소켓 시스템 구성 (섹션 2.1) 때문입니다. 한
소켓의 CPU가 원격 MRAM 뱅크(즉, 다른 소켓)에서 더 낮은 메모리 대역폭
을 확보하기 때문입니다. . BFS 의 경우 추세는 더욱 악화됩니다. DPU 간 동
기화 시간이 크게 증가함에 따라 256개의 DPU가 BFS 실행을 위한 최선의 선
택이 되는 것을 확인했습니다. BFS, SCAN‑SSA 및 SCAN‑RSS에 대한 우리
의 관찰은 작동하는 DPU를 최대한 많이 사용하라는 일반적인 프로그래밍 권
장 사항에 위배됩니다 (섹션 2.3.2). 이 세 가지 벤치마크는 최고 성능의 DPU
수가 DPU 간 동기화 오버헤드에 의해 제한된다는 것을 보여줍니다.
주요 관찰 16
DRAM 처리 장치 전반에 걸친 복잡한 동기화(즉, 호스트 CPU와의 양
방향 통신을 포함하는 DPU 간 동기화)는 상당한 오버헤드를 초래하
여 더 많은 DPU로 확장성을 제한합니다. 이는 DPU가 장착된 경우 더
욱 두드러집니다.
여러 순위의 동기화 범위에 참여했습니다.
5.1.2 약한 스케일링 결과. 그림 15 는 1, 4, 16, 64개 DPU에 대한 단일 순
위 내의 약한 조정 결과를 보여줍니다 . 각 DPU에서 섹션 5.1.1에서 최고의 성
능을 생성하는 태스크릿 수를 실행합니다 . DPU당 데이터 세트의 크기는 표 3
과 같습니다.
강력한 스케일링 결과와 유사하게 DPU("DPU"), DPU 간 동기화 시간
("Inter‑DPU"), CPU‑DPU 및 DPU‑CPU 전송 시간("CPU‑DPU", "DPU‑
CPU") 섹션 5.1.1의 그림 12~14에 나와 있습니다 .
우리는 그림 15에서 다음과 같은 다섯 가지 관찰을 수행합니다.
먼저, 우리는 14개 벤치마크에 대해 DPU에서 완벽한(즉, 선형) 약한 스케일링
을 관찰합니다 . DPU의 실행 시간(즉, 그림 15에서 각 막대의 "DPU" 부분)은
VA, GEMV, SpMV, SEL 에 대해 일정하게 유지됩니다. , UNI, BS, TS, MLP,
HST‑S, HST‑L, RED, SCAN‑SSA, SCAN‑RSS 및 TRNS(DPU 수(및 데이터
세트 크기) 증가). 이러한 커널에서는 DPU 간에 직접적인 통신이 없기 때문에
DPU 간에 워크로드(즉, 로드 밸런싱)를 균등하게 분배 하면 성능 확장이 가능합
니다. BFS 의 DPU 전체에 약간의 로드 불균형이 있음에도 불구하고 BFS에 대
한 완벽한 약한 확장의 유사한 추세를 관찰합니다 .
주요 관찰 17
서로 다른 DPU(DRAM 처리 장치)에 동일한 크기의 문제가 할당되
고 DPU 간 동기화가 거의/전혀 없으면 DPU에 소요되는 실행 시간
이 선형 적으로 약해집니다(즉, RAM 수를 늘릴 때 실행 시간이 일정
하게 유지됨). DPU 및 이에 따른 데이터 세트 크기 ).
25
둘째, NW는 선형적으로 확장되지 않습니다(즉, DPU에 소요되는 실행 시
간이 일정하지 않음). 문제의 크기가 DPU 수에 따라 선형적으로 증가하지 않
기 때문입니다. DPU 수에 따라 입력 시퀀스의 길이를 NW까지 선형적으로 늘
립니다(표 3, 약한 스케일링 데이터 세트 참조). 따라서 2D 점수 행렬의 크기
는 DPU 수에 따라 2차적으로 증가합니다.
결과적으로 DPU 수를 늘리면 DPU의 실행 시간이 늘어납니다. 그러나 2D 점
수 행렬의 가장 긴 대각선은 DPU 수에 따라 선형적으로 증가합니다. 이 대각
선의 처리 시간은 DPU 수를 늘릴 때 선형적으로 약한 스케일링을 보여 줍니
다 . 이러한 실험 결과는 부록(9.2.1절)에 나와 있습니다 .
셋째, DPU 간 동기화가 필요한 벤치마크 (SEL, UNI, BFS, MLP, NW,
HST‑S, HST‑L, RED, SCAN‑SSA, SCAN‑RSS) 중에서 동기화 오버헤드
(즉, 그림 15)의 각 막대에서 "Inter‑DPU" 부분은 SEL, UNI, HST‑S, HST‑
L, RED, SCAN‑SSA 및 SCAN‑RSS의 경우 무시할 수 있습니다 . MLP 및
NW의 경우 DPU 간 동기화 시간 BFS에서는 전체 실행 시간 의 상당 부분을
차지하고 전체 문제 크기(따라서 MLP의 가중치 행렬 크기 및 NW의 반복 횟
수)가 증가하기 때문에 DPU 수에 따라 증가합니다 . 강력한 확장 실험을 위
해 섹션 5.1.1(그림 13 및 14)에서 설명했듯이 DPU 간 동기화 시간은 선형적
으로 증가합니다 . 결과적으로 BFS는 전체 실행 시간(일부 포함) 사이에서 최
상의 균형을 얻습니다. DPU에서 소요된 실행 시간(즉, "DPU" 및 DPU 간
동기화 ("Inter‑DPU")) 및 16개 DPU의 DPU 수(즉, 전체 실행 시간의 비
율, "DPU" 부분 + DPU 수에 대한 "Inter‑DPU" 부분은 16개 DPU의 경우
더 낮습니다.
넷째, CPU‑DPU 및 DPU‑CPU 전송 시간은 메인 메모리와 MRAM 뱅크(VA,
GEMV, SEL(CPU‑DPU만), UNI(CPU‑DPU만) 간 병렬 전송을 사용하는 13개
벤치마크에서 DPU 수에 따라 천천히 증가합니다. DPU), BS, TS, MLP, HST‑
S, HST‑L, RED, SCAN‑SSA, SCAN‑RSS 및 TRNS). 그림 10에서 볼 수 있듯
이 지속적인 CPU‑DPU 및 DPU‑CPU 대역폭은 DPU 수에 따라 선형적으로 증
가합니다. 평균적으로 이 13개 벤치마크에서 1 DPU에서 64 DPU로 지속되는
CPU‑DPU/DPU‑CPU 대역폭의 증가는 20.95×/23.16×입니다. NW는 병렬
CPU‑DPU 및 DPU‑CPU 전송을 사용하지만 전송되는 데이터 양이 증가하므로
CPU‑DPU 전송 및 DPU‑CPU 전송 시간은 DPU 수에 따라 증가합니다(즉, 위
에서 설명한 것처럼 전체 문제 크기가 증가합니다). 그림 15의 두 번째 관찰).
다섯째, 병렬 전송을 사용할 수 없는 벤치마크에서는 CPU‑DPU 전송 및
DPU‑CPU 전송 시간이 DPU 수에 따라 선형적으로 증가합니다 . SEL과 UNI는
위에서 논의한 것처럼 직렬 DPU‑CPU 전송을 사용합니다. 이로 인해 이 두 벤치
마크에서 DPU‑CPU 전송 시간은 DPU 수에 따라 극적으로 증가하여 전체 실행
시간을 지배하게 됩니다. 데이터 세트의 불규칙성으로 인해 병렬 전송을 사용할
수 없는 SpMV 및 BFS에서는 CPU‑DPU 전송 및 DPU‑CPU 전송 시간 도 크게
늘어납니다. SEL, UNI, SpMV 또는 BFS가 응용 프로그램에서 실행되는 여러 커
널 중 하나일 수 있는 본격적인 실제 응용 프로그램에서는 CPU‑DPU 전송 및
DPU‑CPU 전송 시간을 상각하고 오버헤드를 줄일 수 있습니다.
완화.
Machine Translated by Google

700 350 3500 10000

DPU‑CPU DPU‑CPU DPU‑CPU 9000
DPU‑CPU
600 CPU‑DPU 300 CPU‑DPU 3000 CPU‑DPU CPU‑DPU
8000
500
DPU 간 250
DPU 간 2500
DPU 간 DPU 간
7000
DPU DPU DPU DPU
6000
400 200 2000
5000
300 150 1500
4000

200 100 1000 3000

간(
시
행
실

간(
시
행
실

간(
시
행
실

간(
시
행
실
)sm

)sm

)sm

)sm
2000
100 50 500
1000
0 0 0 0
1

1
4

4
61

61

61

61
46

46

46

46
버지니아 GEMV SpMV SEL
#DPU #DPU #DPU #DPU

10000 3000 12000 14000

DPU‑CPU DPU‑CPU
9000
CPU‑DPU 2500 10000 12000 CPU‑DPU
8000
DPU 간 DPU 간
7000 10000
DPU 2000 8000 DPU
6000
8000
5000 1500 6000
4000 DPU‑CPU DPU‑CPU 6000
1000 CPU‑DPU 4000 CPU‑DPU
3000 4000
DPU 간
간(
시
행
실

간(
시
행
실

간(
시
행
실

간(
시
행
실
DPU 간
)sm

)sm

)sm

)sm
2000
500 2000 DPU 2000
1000
DPU

0 0 0 0
1

1
4

4
61

61

61

61
46

46

46

46
유니 학사 TS BFS
#DPU #DPU #DPU #DPU

450 20000 250 600

DPU‑CPU DPU‑CPU
400 18000
CPU‑DPU CPU‑DPU 500
350 16000 200
DPU 간 DPU 간
14000
300 DPU DPU 400
12000 150
250
10000 300
200 DPU‑CPU
8000 100 DPU‑CPU
150 200 CPU‑DPU
6000 CPU‑DPU
DPU 간
간(
시
행
실

간(
시
행
실

간(
시
행
실

간(
시
행
실
100
)sm

)sm

)sm

)sm
4000 50 DPU 간 100 DPU
50 2000 DPU
0 0 0 0
1
4
1

1
4

4
61

61

61

61
46

46

46

46
MLP 북서쪽 HST‑S HST‑L
#DPU #DPU #DPU #DPU

700 1600 1200 18000

DPU‑CPU DPU‑CPU DPU‑CPU DPU‑CPU
1400 CPU‑DPU 16000 CPU‑DPU(1단계)
600 CPU‑DPU CPU‑DPU 1000
DPU 간 DPU 간
DPU 간 14000
500
DPU 간 1200
DPU(스캔)
DPU(3단계)

DPU DPU(스캔) 800 12000 DPU(2단계)

1000 DPU(감소)
400 DPU(추가)
10000
800 600
300 8000
600
400 6000
200
400
간(
시
행
실

간(
시
행
실

간(
시
행
실

간(
시
행
실

4000
)sm

)sm

)sm

)sm

100 200
200 2000

0 0 0 0
1

1
4

4
61

61

61

61
46

46

46

46
빨간색 스캔‑SSA 스캔‑RSS TRNS
#DPU #DPU #DPU #DPU

그림 15: 한 순위(1, 4, 16, 64개 DPU, 약한 확장 사용4)에서 16개 벤치마크의 실행 시간(ms)입니다 . DPU 내부에서는 그림 12에서 가장
성능이 좋은 태스크릿 수를 사용합니다.

주요 관찰 18 5.2 CPU 및 GPU 비교 UPMEM PIM

아키텍처를 성능 및 에너지 소비 측면에서 최신 CPU 및 최
DPU(DRAM 처리 장치) 등급 내에서 병렬 CPU‑DPU/DPU‑CPU 전송의 유지 대
신 GPU와 비교합니다.
역폭은 DPU 수에 따라 선형적으로 증가합니다 .
우리의 목표는 범용 가속기로서 UPMEM PIM 아키텍처의 잠재력을 정량화하
는 것입니다 . 우리는 PIM 구현과 비교하기 위해 최첨단 CPU 및 GPU 버전의
PrIM 벤치마크를 사용합니다 . 벤치마크 의 CPU 및 GPU 버전 소스는 부록
(표 5)에 나열되어 있습니다.

26
Machine Translated by Google

우리는 모든 벤치마크에 대해 640 및 2,556 DPU(표 1)를 갖춘 UPMEM 포인트 곱셈은 기본 지원이 부족하기 때문에 비용이 매우 많이 듭니다 . 세 번째
기반 PIM 시스템을 Intel Xeon E3‑1225 v6 CPU [241] 및 Volta 아키텍처 특성과 관련하여 우리는 섹션 5.1.1의 강력한 스케일링 평가를 통해 DPU 간의
[278] 기반 NVIDIA Titan V GPU [ 277 ]와 비교합니다. . 표 4 에는 CPU, 로드 불균형이 SpMV에 대한 하위선형 스케일링을 유발한다는 것을 알고 있습
GPU 및 두 가지 UPMEM 기반 PIM 시스템 의 주요 특성이 요약되어 있습니다 . 니다. BFS는 섹션 5.1에서 논의한 것처럼 호스트 CPU를 통한 DPU 간 동기화
의 오버헤드가 크기 때문에 UPMEM 기반 PIM 시스템에서 CPU 보다 성능이
UPMEM 기반 PIM 시스템 성능 측정에는 DPU에서 소요된 시간과 UPMEM 훨씬 나쁩니다 . BFS의 DPU 간 동기화 오버헤드는 DPU 수에 따라 선형적으로
기반 PIM 시스템에서 DPU 간 동기화에 소요된 시간이 포함됩니다. CPU 및 증가하므로 2,556‑DPU 시스템은 640‑DPU 시스템보다 상당히 느립니다.15
GPU 성능 측정 에는 커널 시간 만 포함됩니다 (즉, GPU 버전에는 호스트 CPU 이 실험의 목표는 최고의 성능을 보여주는 것이 아닙니다. 주어진 워크로드에 대
와 GPU 간의 데이터 전송이 포함되지 않습니다). 에너지 측정을 위해 CPU에서 해 많은 수의 DPU를 수행하지만 각 워크로드에 대해 2,556개의 DPU와 640개
는 Intel RAPL [279] 을, GPU에서는 NVIDIA SMI [280]를 사용합니다 . 의 DPU가 모두 활성화된 본격적인 시스템의 성능을 발휘합니다 . NW는 DPU
UPMEM PIM 시스템에서는 x86 소켓에서 수행할 수 있는 메모리 컨트롤러에 연 간 동기화 오버헤드로 인해 CPU보다 UPMEM 기반 PIM 시스템에서 한 자릿수
결된 DIMM이 소비하는 에너지를 얻습니다 [281]. 측정에는 PIM 칩의 에너지만 더 느립니다. NW의 DPU 간 동기화 오버헤드는 DPU 수에 따라 달라지지 않습
포함됩니다. 니다. 결과적으로 2,556‑DPU 시스템은 이 벤치마크에서 640‑DPU 시스템과
동일한 성능을 갖습니다.

5.2.1 성능 비교. 그림 16 은 Intel Xeon CPU에 비해 640 및 2,556 DPU와

Titan V GPU를 갖춘 UPMEM 기반 PIM 시스템 의 속도 향상을 보여줍니다 .
셋째, 2,556‑DPU 시스템 은 VA, SEL, UNI, BS, HST‑S, HST‑L, RED,
SCAN‑SSA, SCAN‑ RSS 및 TRNS 등 10개 벤치마크에서 GPU보다 빠릅니
CPU GPU 640개의 DPU 2556개의 DPU 다 . 이 10개 벤치마크는 (1) 스트리밍 메모리 액세스, (2) DPU 간 통신이 없거
1024.000
256.000 나 거의 없음, (3) 정수 곱셈을 사용하지 않거나 거의 사용하지 않는 세 가지 주
64.000
16.000 요 특성으로 인해 UP‑MEM PIM 아키텍처 에 더 적합합니다. , 정수 나누기 또
4.000
1.000 는 부동 소수점 연산. 이러한 벤치마크에서 GPU에 대한 2,556‑DPU 시스템의
0.250
0.063 속도 향상 범위는 6%( SCAN‑SSA의 경우)에서 57.5배 (BS의 경우) 사이이며
0.016
0.004 평균은 2.54배입니다. 전통적으로 GPU 친화적이라고 간주되고 GPU 최적화 연
상
향
도
속
른
따
에
모
규
그
)로
UP C(

0.001
구, 라이브러리 및 VA와 같은 참조 구현의 대상인 일부 벤치마크에서 2,556‑
사
학

ST
아
니
지
버

LES

SFB

PLM
SNRT
‑TSH
L
‑TSH
S

VMpS
VMEG

DPU 시스템이 Titan V 보다 성능 이 뛰어나다는 점은 특히 흥미롭습니다 . ],

NAEMG
NAEMG
A‑S스
캔
S

S‑S스
캔
R

((
1G

((
2G
)1G

)2G
)M

)M
NNAAEEM

NNAAEEM

더더
많은 UPMEM에 적합한워크로드
워크로드(1)
(1) UPMEM에 적합한 워크로드가 적음(2)
(2)
SEL 및 UNI [250, 283], HST‑S 및 HST‑L [260, 272, 284], RED [262,
많은 PIM에 적합한 PIM에 적합하지 않은 워크로드
263], SCAN‑SSA [264, 265, 283], SCAN‑RSS [251, 264, 266, 285] 및
그림 16: 640 및 2,556 DPU, Titan V GPU 및 Intel Xeon E3‑1240 CPU TRNS [269, 270, 286]. 요약하면, UPMEM PIM 아키텍처는 UPMEM 기반
를 갖춘 UPMEM 기반 PIM 시스템 간의 성능 비교. 결과는 CPU 성능으로 정규 PIM 시스템에서 실행하기 에 잠재적으로 적합하게 만드는 세 가지 주요 특성을
화됩니다(y축은 로그 스케일). 벤치마크에는 (1) UPMEM PIM 아키텍처에 더
나타내는 워크로드에 대해 최신 GPU보다 성능이 뛰어납니다 .
적합한 벤치마크와 (2) UPMEM PIM 아키텍처에 덜 적합한 벤치마크의 두 그룹
이 있습니다.

넷째, 640‑DPU 시스템은 일반적으로 GPU보다 느리지 만, 2,556‑DPU

우리는 그림 16에서 네 가지 주요 관찰을 수행합니다. 시스템이 GPU보다 빠른 10개 벤치마크(VA, SEL, UNI, BS, HST‑S, HST‑
첫째, 2,556‑DPU 시스템과 640‑DPU 시스템은 CPU보다 평균 23.2배 및 L, RED, SCAN) ‑SSA, SCAN‑RSS 및 TRNS) 640‑DPU 시스템의 평균 성능
10.1배 빠릅니다. 가장 빠른 속도 향상은 UNI의 경우입니다. 2,556‑DPU 시스 은 GPU 성능의 65% 이내입니다. 이러한 벤치마크 중 640‑DPU 시스템은
템은 CPU보다 629.5배 , 640‑DPU 시스템은 234.4배 빠릅니다. 정수 곱셈 HST‑S와 BS라는 두 가지 벤치마크에서 GPU보다 빠릅니다. 히스토그램의
(GEMV, TS 및 MLP)을 많이 사용하는 벤치마크라도 UPMEM 기반 PIM 시스 GPU 버전 [260, 287] (HST‑S 및 HST‑L과 동일)은 성능에 큰 부담을 주는
템에서는 훨씬 더 빠릅니다( 2,556‑DPU 시스템에서는 5.8‑86.6배 더 빠르며, 원자 연산을 사용합니다 [272]. 결과적으로 640‑DPU 시스템은 HST‑S용
640‑DPU 시스템 에서는 5.6‑25.2배 더 빠릅니다). DPU 시스템). 이러한 관찰 GPU보다 1.89배 빠릅니다. BS의 경우 GPU 버전은 많은 임의 메모리 액세스
은 PIM 지원 메모리의 DIMM으로 시스템을 확장할 경우 CPU가 있는 기존 시스 로 인해 달성 가능한 메모리 대역폭이 크게 감소합니다. 640‑DPU 시스템은
템에서 실행되는 작업 부하가 경험할 수 있는 큰 성능 향상을 반영합니다 ( 그림 BS용 GPU보다 11.0배 빠릅니다.
1 참조).

둘째, UPMEM 기반 PIM 시스템은 SpMV, BFS 및 NW를 제외한 모든 벤치

마크에서 CPU보다 성능이 뛰어납니다. SpMV에는 UPMEM 기반 PIM 시스템
에 적합하지 않은 세 가지 특성이 있습니다. (1) 부동 소수점 데이터에서 작동합
니다. (2) 곱셈을 많이 사용하며 (3) 불규칙한 특성 으로 인해 로드 불균형이 발
생합니다. 희소 행렬. 처음 두 가지 특성과 관련하여 섹션 3.1.2 및 3.3의 분석을 15BFS는 훨씬 적은 수의 DPU를 사용하여 실행함으로써 더 나은 성능을 얻을 수 있습니다.
그 이유 는 섹션 5.1.1 및 5.1.2(그림 13‑15) 에 표시된 것처럼 BFS 성능이 많은 DPU로 확
통해 알 수 있습니다. 장되지 않기 때문입니다 . 그러나 본 실험에서는 모든 DPU를 활용하여 본격적인 시스템 성능
을 연구하므로 훨씬 적은 수의 DPU를 사용하여 BFS를 실행하지 않습니다 .

27
Machine Translated by Google

표 4: 평가된 CPU, GPU 및 UPMEM 기반 PIM 시스템.

프로세스 프로세서 코어 메모리 주파
체계 TDP
마디 총 코어 수 최고 성능 용량 총 대역폭

인텔 제온 E3‑1225 v6 CPU [241] 14nm 4(8개 스레드) 3.3GHz 26.4GFLOPS★ 32GB 37.5GB/초 73W
엔비디아 타이탄 V GPU [277] 14nm 80(5,120 SIMD 레인) 2,5569 2x 1.2GHz 12,288.0GFLOPS 12GB 652.8GB/초 250W

2,556‑DPU PIM 시스템 nm 350MHz 894.6GOPS 159.75GB 1.7TB/초 383W †

640‑DPU PIM 시스템 2xnm 640 267MHz 170.9 GOPS 40GB 333.75GB/초 96W †
★
= 3.3 ×4 ×2 .
† =
/ × 1.2 / [199].

주요 관찰 19 16개 벤치마크 중 12개에 대한 메모리 용량 32GB). 이것

에너지 절약은 이 12가지의 더 낮은 실행 시간에서 비롯됩니다.
UPMEM 기반 PIM 시스템은 640‑DPU 시스템에 대한 벤치마크(그림 16). 우리는 그것을 기대합니다
세 가지 주요 특징을 지닌 워크로드의 최신 GPU : 약 6배 더 많은 DPU를 갖춘 2,556‑DPU 시스템의 에너지 절약
160GB PIM 지원 메모리 및 더 높은 주파수(350 대 267)
1. 스트리밍 메모리 액세스 MHz), 더 높은 성능으로 인해 CPU보다 더 높아질 것입니다.
2. DPU 간 동기화가 없거나 거의 없음 (따라서 정적 에너지가 낮고) 데이터 이동이 적습니다.
3. 정수 곱셈, 정수를 전혀 사용하지 않거나 거의 사용하지 않음 둘째, 640‑DPU 시스템은 640‑DPU 시스템보다 에너지 효율성이 낮습니다.
나누기 또는 부동 소수점 연산 우리의 관찰과 일치하는 SpMV, BFS 및 NW용 CPU
이러한 세 가지 주요 특성으로 인해 작업 부하가 잠재적으로 UPMEM PIM 아키 성능에 대해(섹션 5.2.1)
텍처에 적합해집니다. 셋째, GPU에 비해 640‑DPU 시스템은 더 적은 전력을 소비합니다.
BS 및 HST‑S에 대한 에너지입니다. 이는 BS 및 HST‑S에 대한 두 가지 벤치마크이기 때문입니다.
640‑DPU 시스템이 GPU보다 성능이 뛰어납니다(섹션 5.2.1 참조).
5.2.2 에너지 비교. 그림 17은 에너지 절감 효과를 보여줍니다. 2,556‑DPU 시스템의 경우 에너지 결과는 다음을 따를 것으로 예상됩니다.
640개의 DPU와 Titan V GPU를 갖춘 UPMEM 기반 PIM 시스템 섹션 5.2.1의 성능 결과. 10가지 벤치마크(VA, SEL,
Intel Xeon CPU를 통해. 이 글을 쓰는 시점에서는 2,556‑DPU UNI, BS, HST‑S, HST‑L, RED, SCAN‑SSA, SCAN‑RSS 및 TRNS)
시스템은 에너지 측정을 수행할 수 없지만 우리는 GPU보다 2,556‑DPU 시스템에서 더 빠르게 실행됩니다.
우리 작업의 확장된 버전에 그것들을 포함시키는 것을 목표로 할 것입니다. 또한 에너지를 덜 소비할 가능성이 높습니다. 이것이 가장 큰 원인이기 때문이다.
성능 향상과 에너지 절감은 동일합니다.
CPU GPU
256.00
128.00
640개의 DPU
메모리와 프로세서 간의 데이터 이동 감소
64.00
32.00
UPMEM 기반 PIM 시스템이 제공합니다.
16.00
8.00
4.00 주요 관찰 20
2.00
1.00
0.50
0.25
0.13 UPMEM 기반 PIM 시스템은 성능이 향상되고(즉, 정적 에너지가 낮음) 데이터 이
0.06
0.03 동이 적기 때문에 최신 CPU에 비해 에너지를 크게 절약할 수 있습니다.
사
학

ST
아
니
지
버

LES

SFB
니
유

PLM
SNRT
‑TSH
S

‑TSH
L

VMpS
VMEG
감
절
지
너
한
대
에
모
규
그
)로
UP C(

MGG
NNAAEEM
S‑S스
캔
R
A‑S스
캔
S

((
1G

((
2G
)1G

)2G

메모리와 프로세서 사이.

)M

)M
NNAAEEM

NNAAEEM

더 많은 UPMEM에
더 많은 적합한워크로드
PIM에 적합한 워크로드(1)
(1) UPMEM에 적합한 워크로드가
PIM에 적합하지 적음(2)
않은 워크로드 (2)
UPMEM 기반 PIM 시스템은 워크로드에서 최신 CPU/GPU에 비해 에너지 절약
효과를 제공합니다.
그림 17: UPMEM 기반 에너지 비교
CPU/GPU보다 성능이 뛰어납니다. 소스 때문이에요
640개의 DPU, Titan V GPU 및 Intel을 갖춘 PIM 시스템
성능 향상과 에너지 절감을 동시에 실현
제온 E3‑1240 CPU. 결과는 CPU 성능으로 정규화됩니다(y축은 로그 스케일임). 벤치마크
동일합니다. 메모리와 프로세서 코어 간의 데이터 이동이 크게 감소합니다.
에는 두 가지 그룹이 있습니다. (1) UPMEM에 더 적합한 벤치마크

UPMEM 기반 PIM 시스템은 PIM에 적합한 워크로드를 제공할 수 있습니다.

PIM 아키텍처 및 (2) 적합하지 않은 벤치마크
UPMEM PIM 아키텍처에 적용됩니다.

우리는 그림 17에서 세 가지 주요 관찰을 수행합니다. 5.2.3 토론. 이러한 관찰은 프로그래머에게 유용합니다.
첫째, 640‑DPU 시스템은 평균적으로 1.64배 더 적은 전력을 소비합니다. 얼마나 많은 성능과 에너지를 절약할 수 있는지 예측하기 위해
16개 벤치마크 모두에서 CPU보다 에너지가 더 높습니다. 12개 벤치마크 기존 CPU와 비교하여 UPMEM 하드웨어에서 얻을 수 있는
(VA, GEMV, SEL, UNI, BS, TS, HST‑S, HST‑L, RED, SCAN‑SSA, 다양한 유형의 워크로드를 위한 GPU 시스템.
SCAN‑RSS 및 TRNS), 640‑DPU 시스템은 에너지를 제공합니다. 이 비교의 한 가지 한계는 설정이 어렵다는 것입니다.
CPU에 비해 5.23배 절약됩니다 . 최대 에너지 절감은 세 가지 유형의 시스템(CPU,
UNI의 경우 39.14× . 우리의 실험에 따르면 640‑DPU 시스템은 GPU 및 UPMEM 기반 PIM 시스템)을 사용하여 공정한 비교를 보장합니다.
40GB 용량의 PIM 지원 메모리를 갖춘 이를 위해 640‑DPU PIM 시스템은 비슷한 메모리를 가지고 있습니다.
최신 Intel Xeon CPU에 비해 뛰어난 에너지 절감 효과(포함) CPU 용량(40GB 대 32GB). 그러나 2,556‑DPU

28
Machine Translated by Google
시스템의 메모리 용량은 훨씬 더 높습니다 (~160GB). 반면 , 640‑DPU
UPMEM 기반 PIM 시스템과 GPU는 가격이 비슷합니다(640‑DPU 시스템이
조금 더 저렴함). 제조 기술, 프로세스 노드, 코어 수 또는 주파수(표 5)와 같
은 기타 하드웨어 특성은 섹션 5.2에서 평가하는 네 가지 시스템에서 매우 다
릅니다.
UPMEM 하드웨어는 여전히 성숙하고 있으며 가까운 미래에 더 높은 주파
수(350 또는 267MHz 대신 400‑450MHz)에서 실행될 것으로 예상되며 잠
재적으로 더 작은 기술 노드 로 제조될 수 있습니다 [231]. 따라서 이 비교에
서 보고하는 결과는 UPMEM 기반 PIM 아키텍처의 전체 잠재력을 과소평가
할 수 있습니다 . CPU 및 GPU 시스템은 아키텍처, 소프트웨어 및 제조 측면
에서 수십 년 동안 고도로 최적화되었습니다 . 우리는 PIM 시스템의 아키텍처,
소프트웨어 및 제조가 계속해서 개선될 것이라고 믿습니다( 섹션 6의 향후 개
선에 대한 제안 참조).
6가지 핵심 사항
이 섹션에서는 이 문서 전반에 걸쳐 제공하는 네 가지 주요 내용의 형태로 몇
가지 주요 경험적 관찰을 반복합니다. 또한 UPMEM PIM 아키텍처에 대한 워
크로드 적합성과 우수한 프로그래밍 사례에 대한 시사점을 제공하고 향후 PIM
시스템의 하드웨어 및 아키텍처 설계자를 위한 제안도 제공합니다 .
핵심 내용 #1. UPMEM PIM 아키텍처는 기본적으로 컴퓨팅에 바인딩되어
있습니다. 섹션 3.2에서는 정수 추가보다 더 복잡한 작업이 포함된 작업 부하
가 잠재적으로 메모리 대역폭을 포화시키기 전에 명령 파이프라인을 완전히
활용한다는 것을 보여줍니다. 섹션 3.3에서는 정수 추가와 같이 간단한 작업
을 수행하는 워크로드라도 0.25 작업/바이트(액세스된 정수당 추가 1개)만큼
낮은 작업 강도로 컴퓨팅 처리량을 포화시킨다는 것을 보여줍니다 . 이 핵심 내
용은 UPMEM PIM 아키텍처에 가장 적합한 워크로드가 무엇인지 보여줍니
다.
메모리 바인딩된 워크로드입니다. 프로그래머의 관점에서 볼 때 아키텍처는 계산과 데이터 액세
스에 대해 생각하는 방식의 전환이 필요합니다 . PIM 시스템의 계산 대 데이터 액세스의 상대적
비용이 지배적인 프로세서 중심 아키텍처 의 비용과 매우 다르기 때문입니다. 오늘의.
핵심 내용 1
UPMEM PIM 아키텍처는 기본적으로 컴퓨팅에 바인딩되어
있습니다. 결과적으로 가장 적합한 작업 부하는 메모리 바인
딩되어 있습니다.
핵심 내용 #2. UPMEM PIM 아키텍처에 가장 적합한 워크로드는 산술 연
산이 단순하거나 전혀 없는 워크로드입니다. 이는 DPU가 정수 덧셈/뺄셈과
비트 단위 연산만을 기본적으로 지원하기 때문입니다. 보다 복잡한 정수(예: 곱
셈, 나눗셈) 및 부동 소수점 연산은 소프트웨어 라이브러리 루틴을 사용하여
구현됩니다. 섹션 3.1.2에서는 더 복잡한 정수 연산과 부동 소수점 연산 의 산
술 처리량이 단순 덧셈과 뺄셈의 연산 처리량보다 훨씬 낮다는 것을 보여줍니
다. 섹션 5.2에서는 계산량이 거의 없고 곱셈, 나눗셈 또는 부동 소수점 연산
을 사용하지 않은 벤치마크를 보여줍니다.
29
(16개 벤치마크 중 10개) 최신 NVIDIA Titan V GPU보다 2,556‑DPU 시스
템에서 더 빠르게 실행됩니다(평균 2.54배) . 이러한 관찰은 작업 부하가 다
음 작업에 가장 적합하다는 것을 보여줍니다.
UPMEM PIM 아키텍처는 산술 연산이나 간단한 연산(예: 비트 연산 및 정수 덧셈/뺄셈)이 없
는 아키텍처입니다. 이러한 핵심 내용을 바탕으로 PIM 시스템의 범용 성능을 향상시키기 위해 훨
씬 더 효율적인 소프트웨어 라이브러리 루틴을 고안하거나 , 더 중요하게는 향후 PIM 아키텍처
세대의 복잡한 작업을 위한 전문적이고 빠른 인메모리 하드웨어를 고안하는 것이 좋습니다.
핵심 내용 2
UPMEM에 가장 적합한 워크로드
PIM 아키텍처는 산술 연산을 사용하지 않거나 간단한 연산(예: 비트 연산 및 정수
덧셈/뺄셈)만 사용합니다.
핵심 내용 #3. UPMEM PIM 아키텍처에 가장 적합한 워크로드는 DPU 간에 직접적인 통신
채널이 없기 때문에 글로벌 통신이 거의 없는 워크로드입니다 . 결과적으로 섹션 5.1에서 볼 수
있듯이 DPU 간 통신이 필요하지 않은 벤치마크와 통신이 필요한 벤치마크(특히 MRAM 뱅크
간 병렬 전송을 사용할 수 없는 경우)의 성능 확장성에 큰 차이가 있습니다. 이 핵심 내용은
UPMEM PIM 아키텍처에 가장 적합한 워크로드는 상호 작용이 거의 또는 전혀 없는 워크로드
라는 것을 보여줍니다.
DPU 통신. 이러한 교훈을 바탕으로 하드웨어 아키텍처와 소프트웨어 스택을 향상할 것을 권장
합니다.
DPU 간 통신을 지원합니다(예: 새로운 DRAM 내 데이터 복사 기술 [27, 28, 33, 38, 39, 188,
190] 을 활용하고 DRAM 내부에서 더 나은 연결을 제공 [33, 38]).
핵심 내용 3
UPMEM PIM 아키텍처에 가장 적합한 워크로드는 DRAM 처리 장치 간 통신(DPU
간 통신)이 거의 또는 전혀 필요하지 않습니다.
요약. 현재 형태의 UPMEM PIM 아키텍처 에 가장 적합한 워크로드는 (1) (2) 산술 연산이
단순하거나 전혀 없고 (3) DPU 간 통신이 거의 또는 전혀 없는 메모리 바인딩 워크로드입니다.
핵심 내용 #4. 우리는 기존 UPMEM 기반 PIM 시스템이 우리가 조사한 많
은 워크로드에서 최신 CPU 및 GPU 시스템에 비해 에너지 효율성과 성능을 크
게 향상시키는 것을 확인했습니다 . 섹션 5.2 에서는 전체 16개 PrIM 벤치마
크 세트에서 평균적으로 2,556‑DPU 및 640‑DPU 시스템이 최신 Intel
Xeon CPU보다 각각 23.2배 및 10.1배 더 빠르다는 것을 보여줍니다.
640‑DPU 시스템은 전체 16개 PrIM 벤치마크 세트에서 평균적으로 CPU보
다 1.64배 더 에너지 효율적 이고, 12개 PrIM 벤치마크에서 5.23배 더 에너
지 효율적입니다.
2,556‑DPU 시스템은 16개의 PrIM 벤치마크 중 10개에서 최신 GPU 보
다 더 빠릅니다(평균 2.54배) . 이 벤치마크에는 워크로드의 PIM 적합성을 정
의하는 세 가지 주요 특성이 있습니다. (1)
Machine Translated by Google
스트리밍 메모리 액세스, (2) DPU 간 통신이 거의 또는 전혀 없음 , (3) 곱셈, 나
눗셈 또는 부동 소수점 연산을 거의 또는 전혀 사용하지 않습니다.16 우리는
2,556‑DPU 시스템이
훨씬 더 높은 성능과 성능을 제공할 것으로 기대합니다. 에너지 이점을 제공하
며 향후 PIM 시스템은 더욱 향상될 것입니다(특히 향후 PIM 하드웨어에 대한 권
장 사항을 구현한 후). 핵심 사항 1‑3에 따른 권장 사항을 기반으로 아키텍처가
개선되면 미래의 PIM 시스템이 훨씬 더 매력적이 되어 잠재적으로 모든 워크로드
에 대해 최신 CPU 및 GPU에 비해 훨씬 더 높은 성능과 에너지 이점을 얻을 수 있
을 것이라고 믿습니다 .
핵심 내용 4
• UPMEM 기반 PIM 시스템은 대부분의 PrIM 벤치마크에서 성능 및
에너지 효율성 측면에서 최신 CPU를 능가합니다.
• UPMEM 기반 PIM 시스템은 대부분의 PrIM 벤치마크에서 최신
GPU보다 성능이 뛰어나며 향후 PIM 시스템에 대한 전망은 더욱 긍정
적입니다. • UPMEM 기반 PIM 시스템은 워크로드에서 최신
CPU 및 GPU보다 에너지 효율적 입니다.
CPU 및 GPU 에 비해 성능 향상을 제공합니다 .
7 관련 업무
우리가 아는 한, 이 백서는 실제 PIM 아키텍처에 대한 최초의 오픈 소스 벤치마
크 제품군과 함께 공개적으로 사용 가능한 최초의 실제 PIM 아키텍처에 대한 최
초의 포괄적인 특성화 및 분석을 제공합니다.
PIM 아키텍처에 대한 관련 작업을 간략하게 검토합니다.
PIM에는 두 가지 주요 접근 방식이 있습니다 [1‑4]: (1) 메모리 사용 처리
(PUM) 및 (2) 메모리 근처 처리(PNM). PUM 또는 PNM에 대한 이전 연구에서
는 PIM 아키텍처를 평가하기 위한 실제 상용 시스템이나 벤치마크 제품군 의 결
과를 제공하지 않습니다 .
메모리를 사용한 처리(PUM)는 기존 메모리 아키텍처와 메모리 셀 및 회로의
작동 원리를 활용하여 저렴한 비용으로 각 메모리 칩 내에서 작업을 수행합니다 .
이전 연구에서는 SRAM [21‑24], DRAM [25‑40, 99, 100, 119, 188‑191,
288], PCM [41], MRAM [ 42‑44] 또는 RRAM/memristive [45] 를 사용하
여 PUM 메커니즘을 제안했습니다. –55, 70, 103, 114, 118, 192, 193, 289]
추억. PUM 메커니즘은 데이터 복사 및 초기화 [21, 27, 28, 33, 38, 39, 119,
190], 대량 비트 연산(예: 기능적으로 완전한 부울 논리 연산 세트 ) 과 같은 다양
한 유형의 작업을 가능하게 합니다 . 25, 26, 32, 34, 35, 41–44, 145, 188,
191] 및 간단한 산술 연산(예: 덧셈, 곱셈, 함축 ) [21–24, 29, 35, 36, 45–55 ,
99]. SIMDRAM [37] 이라고 불리는 최근 연구에서는 Ambit 기판[25, 26]을 기
반으로 DRAM 어레이 내부의 비트 직렬 SIMD 방식으로 임의 작업을 구현하고
실행하기 위한 프레임워크를 설계했습니다 .
16이 세 가지 특성은 핵심 시사점 #1~#3에서 강조한 세 가지 특성과 정확히 동일하지
는 않지만 더 구체적입니다. 차이점은 2,556‑DPU 시스템이 스트리밍 메모리 액세스를
통해 메모리 바인딩된 워크로드에 대해 GPU보다 성능이 뛰어나다는 것입니다. 2,556‑
DPU 시스템이 GPU보다 성능이 뛰어난 BS, HST‑S, HST‑L 및 TRNS에도 임의 액세
스가 있으므로 이러한 워크로드에는 스트리밍 메모리 액세스만 필요하지 않습니다 . 모
든 PrIM 워크로드(표 2 참조)에는 일부 스트리밍 메모리 액세스가 포함되어 있으므로
스트라이드 및/또는 랜덤 액세스만 사용하는 워크로드에서는 2,556‑DPU 시스템이
GPU보다 성능이 뛰어나다고 말할 수 없습니다.
30
PNM(Processing Near Memory)은 메모리 근처 또는 내부(예: [8, 56–
69, 71–96 , 98, 101, 104 ) 에 처리 요소 (예: 기능 단위, 가속기, 단순 처리 코
어, 재구성 가능한 논리)를 통합합니다. –110, 113, 120–130, 290, 291]). 이러
한 PNM 작업 중 다수는 3D 스택 메모리의 논리 계층 내부에 PIM 논리를 배치합
니다 [8, 56, 58–67, 75, 78–80, 82, 84–87, 89–95, 101, 106, 108– 111,
113, 128–130, 290, 291], 메모리 컨트롤러 [76, 77], DDRX DIMM [68,
121, 292, 293] 또는 실리콘 인터포저를 통해 연결된 CPU 와 동일한 패키지
[ 57, 126, 127, 186].
또 다른 최근 연구에서는 메모리 일관성 [64‑66], 가상 메모리 [185, 294],
동기화 [56] 또는 워크로드의 PIM 적합성과 같은 PIM 지원 시스템의 시스템 통
합 문제에 대한 솔루션을 연구하고 제안합니다. 128, 184].
여러 연구에서는 생물정보학 [295, 296], 스카이라인 계산 [297], 압축
[298] 또는 희소 선형 대수 [299] 를 위해 UPMEM PIM 아키텍처 가 제공하
는 가속화 기회를 탐구합니다 . 독자는 UPMEM PIM 아키텍처의 특정 애플리
케이션 에 대한 심층 분석을 위해 이러한 작업을 참조할 수 있습니다 . 우리의
작업은 UPMEM PIM 아키텍처의 포괄적인 아키텍처 특성화를 수행하고 PIM
을 연구하는 최초의 작업입니다.
많은 수의 작업 부하에 적합합니다. 또한 우리는 실제 PIM 시스템을 위
한 최초의 벤치마크 제품군을 공개적으로 무료로 제공한 최초의 기업입니
다.
최근 연구 [122, 123]에서는 HBM 기술 [168, 169] 을 기반으로 하는 FIM‑
DRAM이라는 프로그래밍 가능한 뱅크 근처 계산 장치를 갖춘 실제 PIM 시스템
을 제시합니다 . 기계 학습 애플리케이션을 위해 특별히 설계된 FIMDRAM 아키텍
처는 간단한 곱셈 및 누적 단위를 사용하여 SIMD 파이프라인을 구현합니다
[300, 301]. 보다 최근에 발표된 Accelerator‑ in‑Memory [120] 는 딥 러닝
애플리케이션을 위한 곱셈 및 누적 및 활성화 기능을 위한 특수 유닛을 갖춘
GDDR6 기반 PIM 아키텍처입니다 . AxDIMM [121]은 DIMM 의 버퍼 칩에
FPGA 패브릭을 배치하는 DIMM 기반 솔루션입니다 . 추천 추론에 대해 테스트되
었습니다. 보다 일반적인 용도의 UPMEM PIM 아키텍처와 비교할 때 이러한 아
키텍처는 특정 애플리케이션 도메인(예: 기계 학습)에 중점을 두므로 더 넓은 범
위 의 애플리케이션을 지원하는 유연성이 부족할 수 있습니다. 우리 작업 과정에
서 이러한 아키텍처에 대한 포괄적인 특성화 및 분석은 연구원, 프로그래머 및 설
계자가 해당 아키텍처의 잠재력을 이해하는 데 큰 도움이 될 수 있습니다 .
8 요약 및 결론
우리는 실제 상용 PIM 아키텍처에 대한 최초의 포괄적인 특성화 및 분
석을 제시합니다 . 이 분석을 통해 우리는 최초의 공개 PIM 아키텍처
인 UPMEM PIM 아키텍처와 다양한 유형의 워크로드에 대한 적합성
에 대한 엄격하고 철저한 이해를 발전시킵니다 .
먼저 마이크로벤치마크를 사용하여 UPMEM 기반 PIM 시스템의 특성화
를 수행하여 컴퓨팅 처리량 및 메모리 대역폭과 같은 다양한 아키텍처 한계를
평가 하고 새로운 통찰력을 얻습니다. 둘째, 다양한 애플리케이션 도메인(예:
조밀/희소 선형 대수, 데이터베이스, 데이터 분석, 그래프 처리 , 신경망, 생물정
보학, 이미지 처리) 의 16개 메모리 바인딩 워크로드로 구성된 벤치마크 제품
군인 PrIM을 제시합니다 .
Machine Translated by Google

두 가지 대상에서 수행된 PrIM 벤치마크에 대한 광범위한 평가 [13] DE Shaw 외, "NON‑VON 데이터베이스 머신: 간략한 개요", IEEE
데이터베이스공학 황소., 1981.
UPMEM 메모리 모듈을 갖춘 실제 시스템은 PIM 시스템에 대한 다양한 워크로드의 적합
[14] PM Kogge, "EXECUBE ‑ 확장 가능한 MPP를 위한 새로운 아키텍처", ICPP,
성에 대한 새로운 통찰력, 소프트웨어 설계자를 위한 프로그래밍 권장 사항, 미래 PIM 시 1994.

스템의 하드웨어 및 아키텍처 설계자를 위한 제안 및 힌트를 제공합니다. PrIM 벤치마크를 [15] M. Gokhale 등, "메모리 내 처리: Terasys 대규모 병렬 PIM 어레이", IEEE 컴퓨터, 1995.

위한 UPMEM 기반 PIM 시스템의 성능 및 에너지 소비 를 최신 CPU 및 최신 GPU의 성능 [16] D. Patterson 외, "지능형 RAM 사례", IEEE Micro, 1997.
및 에너지 소비와 비교 하고 기존 프로세서 중심에 비해 실제 PIM 시스템 의 주요 강점을 [17] M. Oskin 외, "활성 페이지: 지능형 메모리를 위한 계산 모델"
1998년 ISCA에서.
성공적으로 활용할 수 있는 주요 워크로드 특성을 식별합니다. 아키텍처.
[18] Y. Kang 외, "FlexRAM: 고급 지능형 메모리 시스템을 향하여", in
ICCD, 1999.
[19] K. Mai 외, "스마트 메모리: 모듈식 재구성 가능 아키텍처"
ISCA, 2000.
[20] J. Draper 외, "DIVA 메모리 내 처리 칩의 아키텍처",
우리는 최초의 상용 PIM 시스템을 아키텍처, 소프트웨어 및 제조 측면에서 수 SC, 2002.
십 년 동안 고도로 최적화된 CPU 및 GPU 시스템과 비교했습니다 . PIM 시스 [21] S. Aga 외, "컴퓨팅 캐시", HPCA, 2017.
[22] C. Eckert 외, “신경 캐시: 심층 신경의 비트 직렬 캐시 내 가속
템의 아키텍처, 소프트웨어 및 제조가 지속적 으로 개선됨 에 따라 CPU 및 네트워크”, ISCA, 2018.
GPU 시스템 에 대한 보다 공정한 비교가 가능해지며 , 이는 향후 PIM 시스템 [23] D. Fujiki 외, "데이터 병렬 가속을 위한 이중성 캐시", ISCA, 2019.
에 대한 훨씬 더 높은 이점을 보여줍니다. [24] M. Kang 외, " SRAM에서 계산의 심층 임베딩을 통한 패턴 인식을 위한 에너지 효율적인 VLSI 아키텍
처", ICASSP, 2014.
[25] V. Seshadri 외, "Ambit: 범용 DRAM 기술을 사용한 대량 비트 연산을 위한 인메모리 가속기",
MICRO, 2017.
[26] V. Seshadri 외, "Buddy‑RAM: DRAM을 사용한 대량 비트 연산의 성능 및 효율성 개선",
우리는 우리의 작업이 이 PIM 아키텍처는 물론 미래 PIM 시스템의 프로그래머, 사용
arXiv:1611.09988 [cs:AR], 2016.
자 및 설계자에게 귀중한 통찰력을 제공하고 메모리 중심 컴퓨팅 시스템 개발에 획기적인 [27] V. Seshadri 외, “RowClone: 빠르고 에너지 효율적인 In‑DRAM 대량 데이터
이정표를 제공할 것이라고 믿고 희망합니다 . 복사 및 초기화”, MICRO, 2013.
[28] V. Seshadri 외, "RowClone: DRAM을 사용하여 데이터 이동 및 초기화 가속화", arXiv:1805.03502
[cs.AR], 2018.
[29] S. Angizi 및 D. Fan, “Graphide: 활용하는 그래프 처리 가속기
인드램 컴퓨팅”, GLSVLSI, 2019.
감사의 말 [30] J. Kim 외, "DRAM 대기 시간 PUF: 최신 DRAM 장치의 대기 시간‑신뢰성 균형을 활용하여 물리적 복
제 불가 기능을 신속하게 평가 ", HPCA, 2018.
귀중한 지원을 해주신 UPMEM의 Fabrice Devaux, Rémy Cimadomo, Romaric
Jodin 및 Vincent Palatin에게 감사드립니다 . 우리는 SAFARI Research Group [31] J. Kim 외, "D‑RaNGe: 상용 DRAM 장치를 사용하여 낮은 대기 시간과 높은 처리량으로 실제 난수 생
의 산업 파트너, 특히 ASML, Facebook, Google, Huawei, Intel, Microsoft, 성", HPCA, 2019.
[32] F. Gao 외, “ComputeDRAM: 기성품을 사용한 인메모리 컴퓨팅
VMware 및 Semiconductor Research Corporation 의 지원을 인정합니다 . DRAM”, MICRO, 2019.
Izzat El Hajj 는 베이루트 미국 대학교(URB‑AUB‑103951‑25960)의 대학 연구 위 [33] KK Chang 외, "LISA(Low‑Cost Inter‑Linked Subarrays): DRAM에서 빠른 하위 배열 간 데이터
이동 활성화", HPCA, 2016.
원회의 지원을 인정합니다 .
[34] X. Xin 외, “ELP2IM: 효율적이고 저전력 비트 연산 처리
DRAM에서”, HPCA, 2020.
이 기사는 2021년 제12차 국제 녹색 및 지속 가능한 컴퓨팅 컨퍼런스(IGSC)에서 [35] S. Li 외, "DRISA: A DRAM 기반 재구성 가능 현장 가속기", in
마이크로, 2017.
발표된 우리 작업 의 요약인 [302] 를 크게 확장한 버전입니다 . 3분 토크 영상
[36] Q. Deng 외, "DrAcc: 정확한 CNN 추론을 위한 DRAM 기반 가속기"
(https://youtu.be/SrFD_u46EDA ) , 20분 토크 영상 (https://youtu.be/ DAC에서, 2018.
Pp9jSU2b9oM ), 1‑ 1시간 토크 영상 (https://youtu.be/6Ws3h_ CQO_Q), 롱 [37] N. Hajinazar 외, "SIMDRAM: DRAM을 사용한 비트 직렬 SIMD 처리를 위한 프레임워크", ASPLOS,
2021.
토크 영상 (https://youtu.be/D8Hjy2iU9l4)을 만나보세요. [38] SHS Rezaei 외, “NoM: 은행 간 데이터 전송을 위한 네트워크 온 메모리
고도로 저장된 기억 속에”, CAL, 2020.
[39] Y. Wang 외, "FIGARO: 세분화된 In‑DRAM 데이터 재배치 및 캐싱을 통한 시스템 성능 향상", MICRO,
2020.
[40] MF Ali 외, "범용 DRAM 기술을 사용한 메모리 내 저비용 비트 직렬 추가 ", TCAS‑I, 2019.

참고자료 [41] S. Li 외, "Pinatubo: 신흥 비휘발성 메모리의 대량 비트 연산을 위한 메모리 내 처리 아키텍처", DAC,

[1] O. Mutlu 외, “합당한 곳에서 데이터 처리: 메모리 내 활성화 2016.
계산,” MicPro, 2019. [42] S. Angizi 외, "PIMA‑Logic: 매우 유연하고 에너지 효율적인 논리 계산을 위한 새로운 메모리 내 처리
[2] O. Mutlu 외, "메모리 처리에 관한 최신 입문서", 신흥 컴퓨팅 : 장치에서 시스템으로 ‑ Moore 및 Von 아키텍처", DAC, 2018.
Neumann 너머를 바라보며, 2021, https://arxiv.org/pdf/2012.03112 .pdf. [43] S. Angizi 등, "CMP‑PIM: 에너지 효율적인 비교기 기반 메모리 내 처리 신경망 가속기", DAC, 2018.

[3] S. Ghose 외, "메모리 내 처리: 작업 부하 중심 관점", IBM [44] S. Angizi 등, "AlignS: SOT‑MRAM을 활용한 DNA 짧은 읽기 정렬을 위한 메모리 내 처리 가속기",
JRD, 2019. DAC, 2019.
[4] S. Ghose 외, " 메모리 내 처리에 대한 작업 부하 및 프로그래밍 용이성 중심 관점", arXiv:1907.12947 [45] Y. Levy 외, "Memristive Akers 배열을 사용한 메모리의 논리 연산"
[cs:AR], 2019. 마이크로일렉트로닉스 저널, 2014.
[5] S. Ghose 외, "메모리 내 처리 채택 활성화: 과제, 메커니즘, 향후 연구 방향", arXiv:1802.00320 [46] S. Kvatinsky 외, "MAGIC ‑ Memristor 지원 논리", IEEE TCAS II: Express
[cs:AR], 2018. 브리핑, 2014.
[6] O. Mutlu, "합당한 곳에서 데이터 처리: 메모리 내 컴퓨팅 활성화 ", https://bit.ly/3IVpj0j, 2017, [47] A. Shafiee 외, “ISAAC: 컨볼루셔널 신경망 가속기
MST 기조 연설. 크로스바의 현장 아날로그 산술”, ISCA, 2016.
[7] O. Mutlu 외, "데이터 집약적 컴퓨팅을 위한 메모리 내 및 근처의 실제 처리 활성화", DAC, 2019. [48] S. Kvatinsky et al., "Memristor 기반 IMPLY 논리 설계 절차", ICCD,
2011.
[8] A. Boroumand 외, “소비자 기기를 위한 Google 워크로드: 데이터 완화 [49] S. Kvatinsky 외, “IMPLY(Memristor‑Based Material Implication) 논리: 설계
이동 병목 현상,” ASPLOS, 2018. 원칙과 방법론,” TVLSI, 2014.
[9] D. Pandiyan 및 C.‑J. Wu, IISWC, 2014년 "모바일 플랫폼에서 새로운 스마트폰 워크로드 에 대한 데 [50] P.‑E. Gaillardon 외, "PLiM(Programmable Logic‑in‑Memory) 컴퓨터", DATE, 2016.
이터 이동의 에너지 비용 정량화 ".
[10] G. Kestor 등, "과학 응용 분야에서 데이터 이동의 에너지 비용 정량화", IISWC, 2013. [51] D. Bhattacharjee 외, "ReVAMP: 인 메모리 컴퓨팅을 위한 ReRAM 기반 VLIW 아키텍처", DATE,
2017.
[11] WH Kautz, "셀룰러 메모리 내 논리 어레이", IEEE TC, 1969. [52] S. Hamdioui 외, “Memristor 기반 메모리 내 컴퓨팅 아키텍처
[12] HS Stone, "메모리 내 논리 컴퓨터", IEEE TC, 1970. 데이터 집약적 애플리케이션', DATE, 2015.

31
Machine Translated by Google

[53] L. Xie 외, ICCD, 2015년 "멤리스터 크로스바에 적용되는 빠른 부울 논리". [93] M. Zhang 외, “GraphP: PIM 기반 그래프 프로에 대한 통신 감소‑
[54] S. Hamdioui 외, "컴퓨팅을 위한 멤리스터: 신화인가 현실인가?" DATE, 2017년. 효율적인 데이터 파티션을 통한 중단,” HPCA, 2018.
[55] J. Yu 외, "메모리 내 계산을 위한 멤리스티브 장치", DATE, 2018. [94] Y. Huang 외, " 에너지 효율적인 그래프 처리를 위한 이기종 PIM 하드웨어‑소프트웨어 공동 설계",
[56] C. Giannoula 외, “SyncCron: 근거리 데이터를 위한 효율적인 동기화 지원 IPDPS, 2020.
처리 아키텍처”, HPCA, 2021. [95] Y. Zhuo 외, "GraphQ: 확장 가능한 PIM 기반 그래프 처리", MICRO, 2019.
[57] I. Fernandez 외, “NATSA: 시계열을 위한 근접 데이터 처리 가속기 [96] PC Santos 외, “빅 데이터 처리를 위한 피연산자 크기 재구성
분석”, ICCD, 2020. 기억', DATE, 2017.
[58] M. Alser 외, "게놈 분석 가속화: 지속적인 여정의 입문서" [97] W.‑M. Hwu 외, "컴퓨팅 시스템의 데이터 액세스 계층 구조 재부팅"
IEEE 마이크로, 2020. ICRC, 2017.
[59] DS Cali 외, "GenASM: 게놈 서열 분석을 위한 고성능, 저전력 근사 문자열 매칭 가속 프레임워크", [98] M. Besta 외, “SISA: 그래프 마이닝을 위한 세트 중심 명령어 세트 아키텍처
MICRO, 메모리 내 처리 시스템에 관한 내용,” MICRO, 2021.
2020. [99] JD Ferreira 외, "pLUTo: 대규모 병렬 범용 계산을 가능하게 하는 In‑DRAM 조회 테이블",
[60] JS Kim 외, "GRIM‑Filter: 신흥 메모리 기술을 사용한 읽기 매핑의 빠른 시드 필터링", arXiv:1708.04329 arXiv:2104.07699 [cs.AR], 2021.
[q‑bio.GN], 2017. [100] A. Olgun 외, ISCA, "QUAC‑TRNG: 범용 DRAM에서 4행 활성화를 사용한 고처리량 실제 난수 생성 ",
[61] JS Kim 외, "GRIM‑Filter: 메모리 내 처리 기술을 사용한 DNA 읽기 매핑의 빠른 시드 위치 필터링", ISCA, 2021.
BMC Genomics, 2018.
[62] J. Ahn 외, “PIM 지원 명령어: 낮은 오버헤드, 지역 인식 [101] S. Lloyd 및 M. Gokhale, “불규칙한 데이터에 대한 메모리 내 데이터 재배열‑
메모리 내 처리 아키텍처”, ISCA, 2015. 집중 컴퓨팅,” 컴퓨터, 2015.
[63] J. Ahn 외, “병렬 그래프를 위한 확장 가능한 메모리 내 처리 가속기 [102] DG Elliott 외, "계산 RAM: 메모리에 프로세서 구현"
처리”, ISCA, 2015. IEEE 컴퓨터 설계 및 테스트, 1999.
[64] A. Boroumand et al., “CoNDA: 근거리 데이터에 대한 효율적인 캐시 일관성 지원 [103] L. Zheng 외, "패턴 검색을 위한 RRAM 기반 TCAM", ISCAS, 2016.
가속기”, ISCA, 2019. [104] J. Landgraf 외, "에뮬레이션과 시뮬레이션을 결합하여 근거리 메모리 키/값 조회 가속기 평가", 2021년.
[65] A. Boroumand 외, "LazyPIM: 메모리 내 처리를 위한 효율적인 캐시 일관성 메커니즘", CAL, 2016.
[105] A. Rodrigues 외, "분산‑수집 아키텍처를 향하여: 하드웨어 및 소프트웨어 문제", MEMSYS, 2019년.
[66] A. Boroumand 외, "LazyPIM: 메모리 내 처리 아키텍처에서 캐시 일관성을 위한 효율적인 지원",
arXiv:1706.03162 [cs:AR], 2017. [106] S. Lloyd 및 M. Gokhale, “근접 메모리 가속기의 설계 공간 탐구‑
[67] G. Singh 외, "NAPEL: 앙상블 학습을 통한 근거리 메모리 컴퓨팅 애플리케이션 성능 예측", DAC, 2019. tors”, MEMSYS, 2018.
[107] S. Lloyd 및 M. Gokhale, "근접 메모리 키/값 조회 가속", MEMSYS, 2017.
[68] H. Asghari‑Moghaddam 외, "카멜레온: 대용량 메모리 시스템을 위한 다양하고 실용적인 Near‑
DRAM 가속 아키텍처", MICRO, 2016. [108] M. Gokhale et al., "Near Memory Data Structure Rearrangement", in MEMSYS,
[69] OO Babarinsa 및 S. Idreos, "JAFAR: 데이터베이스를 위한 근거리 데이터 처리", SIGMOD, 2015. 2015.
[109] R. Nair 외, “액티브 메모리 큐브: 메모리 내 처리 아키텍처
[70] P. Chi 외, "PRIME: ReRAM 기반 메인 메모리의 신경망 계산을 위한 새로운 메모리 내 처리 아키텍처", 엑사스케일 시스템,” IBM JRD, 2015.
ISCA, 2016년. [110] AC Jacob 외, "액티브 메모리 큐브용 컴파일", Tech. 대표. RC25644 (WAT1612‑008). IBM 연구 부
[71] A. Farmahini‑Farahani 외, "NDA: 상용 DRAM 장치 및 표준 메모리 모듈을 활용하는 Near‑DRAM 서, 기술. 의원, 2016.
가속 아키텍처", HPCA, [111] Z. Sura 등, "메모리 내 처리 시스템의 데이터 액세스 최적화",
2015. 2015년 CF에서
[72] M. Gao 외, "인메모리 분석 프레임 워크를 위한 실용적인 근거리 데이터 처리", PACT, 2015. [112] R. Nair, "메모리 아키텍처의 진화", IEEE 회보, 2015.
[113] R. Balasubramonian 외, "근접 데이터 처리: MICRO‑46 워크숍의 통찰력", IEEE Micro, 2014.
[73] M. Gao 및 C. Kozyrakis, “HRL: 효율적이고 유연한 재구성 가능 논리
근거리 데이터 처리”, HPCA, 2016. [114] Y. Xi 외, "아날로그 저항 스위칭 메모리를 사용한 메모리 내 학습: 검토 및 관점", IEEE 회보, 2020.
[74] B. Gu 외, "비스킷: 빅 데이터 워크로드의 근거리 데이터 처리를 위한 프레임워크 ", ISCA, 2016.
[115] Onur Mutlu 및 Juan Gómez‑Luna, “미래 컴퓨팅 시스템을 위한 메모리 내 처리 패러다임 탐색(2021
[75] Q. Guo 외, “3D 스택 메모리 측 가속: 가속기 및 시스템 년 가을),” https://safari.ethz.ch/projects_ and_seminars/fall2021/doku.php?
디자인”, WoNDP, 2014. id=processing_in_memory.
[76] M. Hashemi 등, "향상된 메모리 컨트롤러로 종속 캐시 누락 가속화", ISCA, 2016. [116] Onur Mutlu, “컴퓨터 아키텍처(2021년 가을)”, https://safari.ethz.ch/
아키텍처/fall2021/doku.php?id=start.
[77] M. Hashemi 외, “지속적인 런어헤드: 투명한 하드웨어 가속 [117] Onur Mutlu, Mohammed Alser 및 Juan Gómez‑Luna, "컴퓨터 아키텍처 세미나(2021년 가을)",
메모리 집약적인 워크로드용,” MICRO, 2016. https://safari.ethz.ch/architecture_seminar/spring2022/ doku.php?id=start.
[78] K. Hsieh 외, "TOM(투명한 오프로딩 및 매핑): GPU 시스템에서 프로그래머가 투명한 근거리 데이터 처
리 활성화", ISCA, 2016. [118] L. Yavits 등, "GIRAF: 범용 저장 장치 내 저항성 연관 프레임‑
[79] D. Kim 외, "Neurocube: 고밀도 3D 메모리를 갖춘 프로그래밍 가능한 디지털 신경모형 아키텍처", 일”, IEEE TPDS, 2021.
ISCA, 2016. [119] A. Olgun 외, "PiDRAM: DRAM 처리를 위한 전체적인 엔드투엔드 FPGA 기반 프레임워크", arXiv 사전
[80] G. Kim 외, “무제한의 표준화된 근거리 데이터 처리를 향하여” 인쇄 arXiv:2111.00082, 2021.
GPU를 위한 데이터 배치”, SC, 2017. [120] S. Lee 외, " 1TFLOPS MAC 작동 및 딥 러닝 애플리케이션을 위한 다양한 활성화 기능을 지원하는
[81] JH Lee 외, "BSSync: 제한된 부실 일관성 모델을 사용하여 기계 학습 작업을 위한 근거리 메모리 처 1ynm 1.25V 8Gb, 16Gb/s/핀 GDDR6 기반 메모리 내 가속기", ISSCC, 2022.
리", PACT, 2015.
[82] Z. Liu 외, "근접 메모리 컴퓨팅을 위한 동시 데이터 구조", [121] L. Ke 외, “근접 메모리 처리 실행: 개인화 가속화
SPAA, 2017. AxDIMM 권장 사항,” IEEE 마이크로, 2021.
[83] A. Morad 등, "GP‑SIMD 메모리 내 처리", ACM TACO, 2015. Y.‑C. _ Kwon 외, "25.4 머신 러닝 애플리케이션을 위한 뱅크 레벨 병렬성을 사용하는 1.2 TFLOPS 프로그래
[84] L. Nai 외, “GraphPIM: 그래프에서 명령 수준 PIM 오프로딩 활성화 밍 가능 컴퓨팅 장치를 갖춘 HBM2 기반의 20nm 6GB Function‑In‑Memory DRAM ", ISSCC,
컴퓨팅 프레임워크”, HPCA, 2017. 2021.
[85] A. Pattnaik 외, “GPU 아키텍처를 위한 스케줄링 기법 [123] S. Lee 외, " 상용 DRAM 기술 기반 PIM용 하드웨어 아키텍처 및 소프트웨어 스택: 산업용 제품", ISCA,
메모리 내 처리 기능”, PACT, 2016. 2021.
[86] SH Pugsley 외, “NDC: 3D 스택 메모리+로직의 영향 분석 [124] B. Asgari 외, "FAFNIR: 효율적인 근거리 메모리 지능형 감소를 사용하여 희소 수집 가속화", HPCA,
MapReduce 워크로드의 장치”, ISPASS, 2014. 2021.
[87] DP Zhang 외, "TOP‑PIM: 메모리의 처리량 중심 프로그래밍 가능 처리", HPDC, 2014. [125] JM Herruzo 외, " 프로세싱‑니어‑메모리를 사용하여 빠르고 에너지 효율적인 FM‑인덱스 정확한 매칭
활성화", The Journal of Supercomputing, 2021.
[88] Q. Zhu 외, “3D 적층으로 희소 행렬‑행렬 곱셈 가속화 [126] G. Singh et al., “Fpga 기반 현대 데이터의 근접 메모리 가속‑
로직 인 메모리 하드웨어,” HPEC, 2013. 집중 애플리케이션,” IEEE 마이크로, 2021.
[89] B. Akin et al., "3D‑Stacked DRAM을 사용한 메모리의 데이터 재구성", in [127] G. Singh et al., “Near‑Memory Reconfig를 이용한 기상 예측 가속화‑
ISCA, 2015. 내구성 있는 패브릭,” ACM TRETS, 2021.
[90] M. Gao 외, "테트리스: 3D 메모리를 이용한 확장 가능하고 효율적인 신경망 가속", ASPLOS, 2017. [128] GF Oliveira 외, "DAMOV: 데이터 이동 병목 현상 평가를 위한 새로운 방법론 및 벤치마크 제품군",
IEEE Access, 2021.
[91] M. Drumond 외, ISCA의 "몬드리안 데이터 엔진", 2017. [129] A. Boroumand 외, "에지 장치용 Google 신경망 모델: 기계 학습 추론 병목 현상 분석 및 완화",
[92] G. Dai 외, "GraphH: 대규모 그래프 처리를 위한 메모리 내 처리 아키텍처", IEEE TCAD, 2018. PACT, 2021.
[130] A. Boroumand 외, "에지 장치용 Google 신경망 모델: 기계 학습 추론 병목 현상 분석 및 완화", arXiv
사전 인쇄

32
Machine Translated by Google
arXiv:2109.14320, 2021.
[131] A. Denzler 등, "Casper: 캐시 근처 처리를 사용하여 스텐실 계산 가속화", arXiv 사전 인쇄
arXiv:2112.14216, 2021.
[132] U. Kang 외, "DRAM 프로세스 스케일링 향상을 위한 컨트롤러 및 DRAM 공동 설계 ", The Memory
Forum, 2014.
[133] J. Liu 등, ISCA의 "현대 DRAM 장치의 데이터 보존 동작에 대한 실험적 연구: 보존 시간 프로파일링 메커
니즘에 대한 함의",
2013.
[134] O. Mutlu, “메모리 확장: 시스템 아키텍처 관점”, IMW, 2013.
[135] Y. Kim 외, "액세스하지 않고 메모리의 비트 뒤집기: DRAM 외란 오류에 대한 실험적 연구", ISCA, 2014.
[136] O. Mutlu, "메모리 밀도가 높아짐에 따라 직면할 수 있는 RowHammer 문제 및 기타 문제 ", DATE,
2017.
[137] S. Ghose 외, "DRAM 전력 모델이 알려주지 않는 것: 상세한 실험 연구에서 얻은 교훈", SIGMETRICS,
2018.
[138] O. Mutlu와 L. Subramanian, “기억의 연구 문제와 기회
시스템”, SUPERFRI, 2014.
[139] JS Kim 외, "RowHammer 재검토: 최신 DRAM 장치 및 완화 기법에 대한 실험적 분석", ISCA, 2020.
[140] O. Mutlu와 JS Kim, “RowHammer: 회고전”, IEEE TCAD, 2019.
[141] P. Frigo 외, "TRRespass: 대상 행 새로 고침의 다양한 측면 활용"
S&P에서는 2020년.
[142] J. Kim 외, “Solar‑DRAM: 다음을 활용하여 DRAM 액세스 지연 시간 단축
로컬 비트라인의 변형”, ICCD, 2018.
[143] J. Liu 외, "RAIDR: 보존 인식 지능형 DRAM 새로 고침", ISCA, 2012.
[144] O. Mutlu, "주 메모리 확장: 과제 및 솔루션 방향", 차세대 컴퓨터 설계를 위한 무어 기술 이상. 스프링거,
2015.
[145] JA Mandelman 외, " DRAM(동적 랜덤 액세스 메모리)의 확장에 대한 과제 및 향후 방향", IBM JRD,
2002.
[146] BC Lee 외, "확장 가능한 DRAM 대안으로서 위상 변화 메모리 설계", ISCA, 2009.
[147] L. Cojocar 등, “우리는 Rowhammer에 취약합니까? 엔드투엔드(End‑to‑End) 방법‑
클라우드 제공업체를 위한 이론”, S&P, 2020.
[148] AG Ya likçi 외, "BlockHammer: 빠르게 액세스되는 DRAM 행을 블랙리스트에 추가하여 저렴한 비
용으로 RowHammer 방지", HPCA, 2021.
[149] M. Patel 외, ISCA, "REAPER(The Reach Profiler): 공격적인 조건에서 프로파일링을 통해 DRAM 보
유 오류 완화 활성화", 2017년.
[150] S. Khan 외, "DRAM 유지 실패에 대한 오류 완화 기술의 효율성: 비교 실험 연구", SIGMETRICS, 2014.
[151] S. Khan 외, “PARBOR: 데이터 탐지를 위한 효율적인 시스템 수준 기술
DRAM의 종속 오류”, DSN, 2016.
[152] S. Khan 외, " 현재 메모리 콘텐츠를 활용하여 데이터 종속 DRAM 오류 감지 및 완화", MICRO, 2017.
[153] D. Lee 외, "적응형 지연 DRAM: 일반적인 경우에 대한 DRAM 타이밍 최적화", HPCA, 2015.
[154] D. Lee 외, "현대 DRAM 칩의 설계로 인한 지연 시간 변화: 특성화 , 분석 및 지연 시간 감소 메커니즘",
SIGMETRICS, 2017.
[155] KK Chang 외, "현대 DRAM 장치의 감소된 전압 작동 이해: 실험적 특성화, 분석 및 메커니즘", SIG‑
METRICS, 2017.
[156] KK Chang 외, "현대 DRAM 칩의 지연 시간 변화 이해: 실험적 특성화, 분석 및 최적화", SIGMETRICS,
2016.
[157] KK Chang 외, " 액세스와 새로 고침을 병렬화하여 DRAM 성능 향상", HPCA, 2014.
[158] J. Meza 외, “대규모 생산 데이터 센터의 메모리 오류 재검토:
현장의 새로운 동향 분석 및 모델링,” DSN, 2015.
[159] H. David 등, “동적 전압/주파수를 통한 메모리 전력 관리
스케일링”, ICAC, 2011.
[160] Q. Deng 외, "Memscale: 메인 메모리를 위한 활성 저전력 모드", ASPLOS, 2011.
[161] 홍상현, “메모리 기술 동향과 미래 과제”, IEDM, 2010.
[162] S. Kanev 외, ISCA, 2015년 "창고 규모 컴퓨터 프로파일링".
[163] MK Qureshi 외, "AVATAR: DRAM 시스템을 위한 가변 유지 시간(VRT) 인식 새로 고침 ", DSN, 2015.
[164] L. Orosa 등, "RowHammer의 감도에 대한 심층 조사: 실제 DRAM 칩의 실험적 분석 및 향후 공격 및
방어에 대한 영향" , MICRO, 2021.
[165] H. Hassan 외, "In‑DRAM RowHammer 보호 메커니즘 발견: 새로운 방법론, 맞춤형 RowHammer
패턴 및 의미", MICRO,
2021.
[166] M. Patel 외, "Harp: 온다이 오류 수정 코드를 사용하는 메모리 칩에서 수정 불가능한 오류를 실질적이
고 효과적으로 식별", MICRO‑54: 54회 연례 IEEE/ACM 마이크로아키텍처에 관한 국제 심포지엄,
2021, 623쪽~
640.
[167] 하이브리드 메모리 큐브 컨소시엄, “HMC 사양 2.0,” 2014.
[168] JEDEC, "고대역폭 메모리(HBM) DRAM", 표준 번호 JESD235, 2013.
33
[169] D. Lee 외, "동시 다층 액세스: 저렴한 비용으로 3D 스택 메모리 대역폭 개선", TACO, 2016.
[170] S. Ghose et al., "복잡한 작업 부하‑DRAM 상호 작용의 신비를 풀기:
실험 연구”, SIGMETRICS, 2019.
[171] Y. Kim 외, "Ramulator: 빠르고 확장 가능한 DRAM 시뮬레이터", CAL, 2015.
[172] M. Gokhale et al., “ 2015년 하이브리드 메모리 큐브 성능 특성화.
데이터 중심 워크로드”(IA3) ,
[173] E. Kültürsay 외, ISPASS, 2013년 "에너지 효율적인 주 메모리 대안으로 STT‑RAM 평가".
[174] DB Strukov 등, "The Missing Memristor Found", Nature, 2008.
[175] H.‑SP Wong 등, "금속 산화물 RRAM", Proc. IEEE, 2012.
[176] BC Lee 외, “Phase Change Memory Architecture and the Quest for Scalabil‑
ity,” CACM, 2010.
[177] MK Qureshi et al., “확장 가능한 고성능 메인 메모리 시스템
상변화 메모리 기술,” ISCA, 2009.
[178] P. Zhou 외, “위상을 사용하는 내구성 있고 에너지 효율적인 메인 메모리
메모리 기술 변경,” ISCA, 2009.
[179] BC Lee 외, “상변화 기술과 메인 메모리의 미래,”
IEEE 마이크로, 2010.
[180] H.‑SP Wong 등, "Phase Change Memory," Proc. IEEE, 2010.
[181] H. 윤 외, “다단계 세포 상변화 메모리를 위한 효율적인 데이터 매핑 및 버퍼링 기술”, ACM TACO, 2014.
[182] H. 윤 외, "하이브리드 메모리에 대한 행 버퍼 위치 인식 캐싱 정책 ", ICCD, 2012.
[183] P. Girard 등, "자기 랜덤 액세스 메모리에 대한 테스트 및 신뢰성 솔루션 조사 ", IEEE 회보, 2020.
[184] GF Oliveira 등, "DAMOV: 데이터 이동 병목 현상을 평가하기 위한 새로운 방법론 및 벤치마크 제품군",
arXiv:2105.03725 [cs.AR], 2021.
[185] K. Hsieh 등, "3D 스택 메모리에서 포인터 추적 가속화: 과제 , 메커니즘, 평가", ICCD, 2016.
[186] G. Singh 외, "NERO: 날씨 예측 모델링을 위한 근 고대역폭 메모리 스텐실 가속기", FPL, 2020.
[187] R. Hadidi 등, "CAIRO: 메모리 내 처리의 명령어 수준 오프로딩을 활성화하기 위한 컴파일러 지원 기술",
ACM TACO, vol. 2017년 14월 14일
[188] V. Seshadri 및 O. Mutlu, "In‑DRAM 대량 비트 단위 실행 엔진", arXiv:1905.09822 [cs.AR], 2020.
[189] V. Seshadri 및 O. Mutlu, "메모리 패러다임을 사용한 처리: DRAM 내 대량 복사, 초기화, 비트 AND
및 OR", arXiv:1610.09603 [cs:AR], 2016.
[190] V. Seshadri 및 O. Mutlu, “데이터 이동을 줄이기 위한 메모리에서의 간단한 작업‑
ment,” 컴퓨터 발전, 106권, 2017년.
[191] V. Seshadri 외, “DRAM의 고속 대량 비트 AND 및 OR”, CAL, 2015.
[192] A. Ankit 외, "PUMA: 기계 학습 추론을 위한 프로그래밍 가능 초효율 멤리스터 기반 가속기", ASPLOS,
2019.
[193] A. Ankit 외, "PANTHER: 에너지 효율적인 ReRAM을 활용하는 신경망 훈련을 위한 프로그래밍 가능 아
키텍처 ", IEEE TC, 2020.
[194] J. Ambrosi 외, “아날로그‑디지털 가속을 위한 하드웨어‑소프트웨어 공동 설계‑
기계 학습을 위한 토르”, ICRC, 2018.
[195] P. Bruel 등, ICRC, "일반화 또는 다이: 멤리스터 기반 가속기에 대한 운영 체제 지원", 2017.
[196] S. Huang 외, “ReRAM 기반 DNN 추론을 위한 혼합 정밀 양자화
가속기”, ASP‑DAC, 2021.
[197] Y. Kim 외, "DRAM에서 하위 배열 수준 병렬 처리(SALP)를 활용하는 사례", ISCA, 2012.
[198] UPMEM, “UPMEM PIM 소개. DRAM 가속기의 PIM(Processing‑in‑Memory) (백서),” 2018.
[199] F. Devaux, "메모리 가속기의 진정한 처리", Hot Chips, 2019.
[200] D. Weber et al., "DRAM 금속화의 현재 및 미래 과제", in
IITC, 2005.
[201] Y. Peng 외, " 3D DRAM의 DC 전력 무결성을 위한 설계, 패키징 및 아키텍처 정책 공동 최적화", DAC,
2015.
[202] M. Yuffe 외, "완전 통합형 다중 CPU, GPU 및 메모리 컨트롤러 32nm 프로세서", ISSCC, 2011.
[203] R. Christy 외, “8.3 인프라용 7nm FinFET의 3GHz ARM Neoverse N1 CPU‑
구조 응용 프로그램”, ISSCC, 2020.
[204] T. Singh 외, "3.2 Zen: 차세대 고성능 x86 코어", in
ISSCC, 2017.
[205] O. Mutlu, “강의 18c: 세분화된 멀티스레딩,” https://safari. ethz.ch/digitaltechnik/spring2020/
lib/exe/fetch.php?media=onur‑ digitaldesign‑2020‑lecture18c‑fgmt‑
beforelecture.pptx, 비디오는 http://www.youtube.com/watch?v=bu5dxKTvQVs 에서 볼
수 있습니다. , 2020, 디지털 디자인 및 컴퓨터 아키텍처. 2020년 봄.
[206] JL Hennessy 및 DA Patterson, 컴퓨터 아키텍처 ‑ 정량적 접근 방식, 5판, 3장: 명령어 수준 병렬 처리
및 활용.
모건 카우프만, 2012.
[207] BJ Smith, "파이프라인된 공유 리소스 MIMD 컴퓨터", ICPP, 1978.
Machine Translated by Google
[208] BJ Smith, "HEP 다중 프로세서 컴퓨터 시스템의 아키텍처 및 응용", SPIE, 실시간 신호 처리 IV, 1981.
[209] JE Thornton, CDC 6600: 컴퓨터 설계, 1970.
[210] O. Mutlu, “강의 19: SIMD 프로세서,” https://safari.ethz.ch/digitaltechnik/ spring2020/lib/exe/
fetch.php?media=onur‑digitaldesign‑2020‑lecture19‑simd‑ beforelecture.pptx, 비디오는
http://www.youtube.com/watch?v= 에서 볼 수 있습니다. 2XZ3ik6xSzM, 2020, 디지털 디자인과
컴퓨터 아키텍처. 2020년 봄.
[211] JL Hennessy 및 DA Patterson, 컴퓨터 아키텍처 ‑ 정량적 접근 방식, 5판, 4장: 벡터, SIMD 및 GPU 아키
텍처 의 데이터 수준 병렬 처리 . 모건 카우프만, 2012.
[212] MJ 플린, "초고속 컴퓨팅 시스템", Proc. IEEE, 1966.
[213] 업멤(UPMEM), “업멤 사용자 매뉴얼. 버전 2021.1.0,” 2021.
[214] SAFARI 연구 그룹, "PrIM Benchmark Suite", https://github.com/CMU‑SAFARI/prim‑
benchmarks .
[215] S. Williams 외, “Roofline: 다중 환경을 위한 통찰력 있는 시각적 성능 모델
핵심 아키텍처,” CACM, 2009.
[216] G. Hager 및 G. Wellein, 과학자 및 엔지니어를 위한 고성능 컴퓨팅 소개 , 5장: 병렬화의 기초. CRC 출판
사, 2010.
[217] GM Amdahl, "대규모 달성을 위한 단일 프로세서 접근 방식의 타당성 ", AFIPS, 1967.
[218] JL Gustafson, "암달의 법칙 재평가", CACM, 1988.
[219] A. Saini, "인텔 펜티엄 프로세서 설계", ICCD, 1993.
[220] D. Jaggar, "ARM 아키텍처 및 시스템", IEEE 통신 역사 연보
퍼팅, 1997.
[221] AS Waterman, "RISC‑V 명령어 세트 아키텍처 설계", Ph.D. 논문, UC 버클리, 2016.
[222] Y. Kim 및 O. Mutlu, 컴퓨팅 핸드북: 컴퓨터 과학 및 소프트웨어 엔지니어링, 3판, 1장: 메모리 시스템. CRC
출판사, 2014.
[223] O. Mutlu, "강의 2b: 데이터 보존 및 메모리 새로 고침", https: //bit.ly/3KhVgAq, 비디오는 http://
www.youtube.com/watch?v= 에서 볼 수 있습니다. v702wUnaWGE, 2020, 컴퓨터 아키텍처. 2020
년 가을.
[224] O. Mutlu, "강의 3b: 기억 시스템: 도전과 기회," https://bit.ly/3sQIfYu, 비디오는 http://
www.youtube.com/watch?v= 에서 볼 수 있습니다. Q2FbUxD7GHs, 2020, 컴퓨터 아키텍처. 2020
년 가을.
[225] O. Mutlu, “강의 4a: 메모리 시스템: 솔루션 방향,” https://safari.ethz.ch/architecture/fall2020/lib/
exe/fetch.php?media=onur‑ comparch‑fall2020‑lecture4a‑ memory‑solutions‑
afterlecture.pptx, 비디오는 http://www.youtube.com/watch?v=PANTCVTYe8M에서 볼 수 있
습니다., 2020, 컴퓨터 아키텍처. 2020년 가을.
[226] JEDEC, “JESD79‑4 DDR4 SDRAM 표준,” 2012.
[227] UPMEM, “UPMEM 웹사이트,” https://www.upmem.com, 2020.
[228] V. Seshadri 외, "집합 분산형 DRAM: 비단위 스트라이드 액세스의 공간적 지역성을 개선하기 위한 DRAM
내 주소 변환", MICRO, 2015년.
[229] Intel, "Intel Xeon Silver 4215 프로세서", https://ark.intel.com/content/www/us/
en/ark/products/193389/intel‑xeon‑silver‑4215‑processor‑11m‑cache‑2‑50‑
ghz.html, 2019.
[230] Intel, "Intel Xeon Silver 4110 프로세서", https://ark.intel.com/content/www/us/
en/ark/products/123547/intel‑xeon‑silver‑4110‑processor‑11m‑cache‑2‑10‑
ghz.html, 2017.
[231] R. Jodin 및 R. Cimadomo, “UPMEM. 개인 커뮤니케이션,” 2020년 10월.
[232] O. Mutlu, “강의 20: 그래픽 처리 장치,” https://safari. ethz.ch/digitaltechnik/spring2020/lib/exe/
fetch.php?media=onur‑ digitaldesign‑2020‑lecture20‑gpu‑beforelecture.pptx,
비디오는 http://www.youtube.com/watch?v=dg0VN 에서 볼 수 있습니다. ‑XCGKQ, 2020, 디지털
디자인과 컴퓨터 아키텍처. 2020년 봄.
[233] T. Rauber 및 G. Rünger, 병렬 프로그래밍, 2판, 3장: 병렬
프로그래밍 모델. 스프링거, 2013.
[234] UPMEM, “UPMEM 소프트웨어 개발 키트(SDK).” https://sdk.upmem.com,
2021.
[235] C. Lattner 및 V. Adve, “LLVM: 평생 프로그램을 위한 컴파일 프레임워크
분석 및 변환”, CGO, 2004.
[236] UPMEM, “컴파일러 탐색기,” https://dpu.dev, 2020.
[237] JD McCalpin, "현재 고성능 컴퓨터의 메모리 대역폭 및 머신 밸런스 ", IEEE TCCA 뉴스레터, 1995.
[238] LLVM, “Compiler‑RT, LLVM 프로젝트,” https://github.com/llvm/llvm‑project/
트리/메인/컴파일러‑rt/lib/buildins, 2021.
[239] PR Luszczek 외, "HPCC(HPC Challenge) 벤치마크 제품군", SC, 2006.
[240] 인텔, "인텔 고급 벡터 확장 프로그래밍 참조", 2011.
[241] Intel, “Intel Xeon 프로세서 E3‑1225 v6, ” https://ark.intel.com/content/www/us/
en/ark/products/97476/intel‑xeon‑processor‑e3‑1225‑v6 ‑8m‑캐시‑3‑30‑
ghz.html, 2017.
[242] 인텔, “인텔 어드바이저”, 2020.
[243] LS Blackford 등, "기본 선형 대수 하위 프로그램 (BLAS)의 업데이트된 세트", ACM TOMS, 2002.
[244] Y. Saad, 희소 선형 시스템을 위한 반복 방법, 2판, 1장:
병렬 구현. 시암, 2003.
[245] Y. Saad, 희소 선형 시스템을 위한 반복 방법, 제2판, 3장: 희소
행렬. 시암, 2003.
34
[246] W. Liu 및 B. Vinter, "CSR5: 크로스 플랫폼 희소 행렬 벡터 곱셈을 위한 효율적인 저장 형식", ICS, 2015.
[247] K. Kanellopoulos 등, "SMASH: 효율적인 희소 행렬 연산을 위한 소프트웨어 압축 및 하드웨어 가속 인덱
싱 공동 설계", MICRO , 2019.
[248] S. Ceri 및 G. Gottlob, "SQL을 관계형 대수학으로 변환: SQL 쿼리의 최적화, 의미 및 동등성", IEEE TSE,
1985.
[249] GE Blelloch, "기본 병렬 작업으로 스캔", IEEE TC, 1989.
[250] J. Gómez‑Luna 외, “다코어 아키텍처를 위한 내부 데이터 슬라이딩 알고리즘”
강의”, ICPP, 2015.
[251] S. Yan 외, “StreamScan: 전역 장벽이 없는 GPU용 고속 스캔 알고리즘
동기화”, PPoPP, 2013.
[252] DE Knuth, "최적 이진 검색 트리", Acta informatica, 1971.
[253] C.‑CM Yeh 외, "행렬 프로필 I: 시계열에 대한 모든 쌍 유사성 조인: 모티프, 불일치 및 셰이프릿을 포함하는
통합 보기", ICDM, 2016.
[254] Y. Zhu 외, "행렬 프로파일 XI: SCRIMP++: 대화형 속도의 시계열 모티브 발견", ICDM, 2018.
[255] A. Bundy 및 L. Wallen, 인공 지능 도구 카탈로그의 "폭 우선 검색" . 스프링거, 1984.
[256] DB Kirk 외, 대규모 병렬 프로세서 프로그래밍, 제3판, 12장 ‑ 병렬 패턴: 그래프 검색. 모건 카우프만, 2017.
[257] L. Luo 외, "폭 우선 검색의 효과적인 GPU 구현", DAC,
2010.
[258] GE Hinton, “대규모 병렬 방식으로 번역 불변 인식 학습
네트워크”, PARLE, 1987.
[259] S. Needleman 및 C. Wunsch, " 두 단백질의 아미노산 서열 유사성 검색에 적용할 수 있는 일반적인 방법
", Journal of Molecular Biology, 1970.
[260] J. Gómez‑Luna 외, " GPU의 히스토그램 계산에 대한 최적화된 접근 방식", MVAP, 2013.
[261] R. Rabenseifner, ICCS의 "집단적 감축 운영 최적화",
2004.
[262] M. Harris, "CUDA의 병렬 축소 최적화", Nvidia 개발자 기술 ‑
오기, 2007.
[263] SG De Gonzalo 외, " GPU에서 빠르고 휴대 가능한 병렬 축소를 위한 워프 수준 프리미티브 및 원자 명령의
자동 생성", CGO, 2019.
[264] DB Kirk 외, 대규모 병렬 프로세서 프로그래밍, 제3판, 8장 ‑ 병렬 패턴: 접두사 합계: 병렬 알고리즘의 작업 효
율성 소개 . 모건 카우프만, 2017.
[265] S. Sengupta 외, "GPU를 위한 효율적인 병렬 스캔 알고리즘", NVIDIA 기술 보고서 NVR‑2008‑003,
2008.
[266] Y. Dotsenko 외, "그래픽 프로세서의 고속 스캔 알고리즘", ICS, 2008.
[267] A. 케일리, “II. 행렬 이론에 관한 회고록,” 런던 왕립학회의 철학적 거래, 1858년.
[268] TW Hungerford, 추상 대수학: 소개, 제3판. 센게이지 학습, 2012.
I.‑J. _ Sung 외, "가속기에서 직사각형 행렬의 내부 전치", PPoPP, 2014.
[270] J. Gomez‑Luna 외, "GPU의 내부 행렬 전치", IEEE TPDS, 2016.
I.‑J. _ Sung et al., “DL: 이기종 데이터 레이아웃 변환 시스템
컴퓨팅”, 혁신적인 병렬 컴퓨팅, 2012.
[272] J. Gómez‑Luna 등, “GPU에서 원자 추가의 성능 모델링
스크래치패드 메모리,” IEEE TPDS, 2013.
[273] RF Boisvert 외, "매트릭스 시장: 테스트 매트릭스 컬렉션을 위한 웹 리소스"
수치 소프트웨어 품질 분야, 1996년.
[274] E. Cho 외, “우정과 이동성: 위치 기반 소셜에서의 사용자 이동
네트워크”, KDD, 2011.
[275] D. Chakrabarti 등, "R‑MAT: 그래프 마이닝을 위한 재귀 모델", SDM,
2004.
[276] JH van Hateren 및 A. van der Schaaf, "1차 시각 피질의 단순 세포와 비교한 자연 이미지의 독립 구성 요
소 필터", 런던 왕립 학회 회보. 시리즈 B: 생물학, 1998.
[277] NVIDIA, “NVIDIA Titan V,” https://www.nvidia.com/en‑us/titan/titan‑v/, 2017.
[278] NVIDIA, “NVIDIA Tesla V100 GPU 아키텍처. 백서,” https://images.nvidia.com/content/volta‑
architecture/pdf/volta‑architecture‑whitepaper.pdf , 2017.
[279] 인텔 오픈 소스, “RAPL 파워 미터,” https://01.org/rapl‑power‑meter, 2014.
[280] NVIDIA, "NVIDIA 시스템 관리 인터페이스 프로그램", http://developer. download.nvidia.com/
compute/DCGM/docs/nvidia‑smi‑367.38.pdf, 2016.
[281] Intel, "Intel 64 및 IA‑32 아키텍처 소프트웨어 개발자 매뉴얼," 볼륨 3B: 시스템 프로그래밍 가이드, 2011.
[282] NVIDIA, “CUDA 샘플 v. 11.2,” 2021.
[283] N. Bell 및 J. Hoberock, “Thrust: CUDA를 위한 생산성 중심 라이브러리,”
GPU 컴퓨팅 보석, Jade Edition, 2012.
G.‑J. _ van den Braak 외, " GPU 스크래치패드 메모리의 원자적 연산 시뮬레이션 및 아키텍처 개선", ICCD, 2013
년.
Machine Translated by Google

[285] D. Merrill 및 NVIDIA‑Labs, “CUDA 언바운드(CUB) 라이브러리,” NVIDIA‑Labs, 둘째, 낮은 작업 강도의 경우 포화 처리량에 도달하는 데 필요한 태스크릿
2015.
수는 11개 미만입니다. 이는 MRAM 액세스 지연 시간이 전체 지연 시간을 지배
[286] B. Catanzaro 외, "내부 행렬 전치에 대한 분해", in
PPoPP, 2014. 하는 메모리 바인딩 영역에서 발생합니다. 이 관찰은 섹션 3.2.2의 COPY 및
[287] J. Gómez‑Luna et al., “Chai: 협업을 위한 이기종 애플리케이션 ADD 벤치마크에 대한 관찰 과 일치합니다 .
통합 아키텍처”, ISPASS, 2017.
[288] V. Seshadri, "고효율 메모리 시스템을 활성화하기 위한 간단한 DRAM 및 가상 메모리 추상화 ", Ph.D.
카네기멜론대학교 논문,
2016.
9.2 Needleman‑Wunsch, 이미지 히스토그램, 축소 및 스캔에 대한 확장된
[289] L. Song 외, "GraphR: ReRAM을 사용하여 그래프 처리 가속화", HPCA,
2018. 결과 이 섹션에서는 PrIM 벤치마크 중 4개에 대한 몇 가지 추가
[290] A. Boroumand et al., "폴리네시아: 특수 하드웨어/소프트웨어 공동 설계를 통한 효과적인 하이브리
드 트랜잭션‑알/분석 데이터베이스 활성화", arXiv:2103.00798 [cs.AR], 2021.
결과를 제시합니다. 먼저, 우리는 NW에 대한 확장된 평가를 제시합니다( 9.2.1절).
둘째, 다양한 히스토그램 크기에 대해 HST‑S와 HST‑L을 비교합니다 (9.2.2절).
[291] A. Boroumand 외, "에지 기계 학습 추론 병목 현상 완화: Google Edge 모델 가속화에 대한 실증적 셋째, 로컬 내부 DPU 감소를 수행하기 위한 세 가지 다른 메커니즘을 사용하여
연구", arXiv:2103.00768 [cs.AR], 2021.
RED를 평가하는 방법을 보여줍니다 (9.2.3절). 넷째, 서로 다른 배열 크기에 대해
[292] MA Alves et al., “벡터 연산 수행의 기회와 과제 SCAN‑SSA와 SCAN‑RSS를 비교합니다 (9.2.4절).
DRAM 내부의 기능”, MEMSYS, 2015.
[293] W. Huangfu 외, "MEDAL: DNA 시딩 알고리즘을 위한 확장 가능한 DIMM 기반 근거리 데이터 처리
가속기", MICRO, 2019.
[294] N. Hajinazar 외, "가상 블록 인터페이스: 기존 가상 메모리 프레임워크에 대한 유연한 대안", ISCA,
2020. 9.2.1 니들만‑분쉬. NW의 약한 스케일링 실험에 대한 추가 결과를 제시합니
[295] D. Lavenier 등, "Processor‑in‑Memory 아키텍처를 사용한 DNA 매핑", 다. 본 실험에서는 DPU 수에 비례하여 정렬되도록 시퀀스 길이를 늘립니다 . 따
BIBM, 2016.
[296] D. Lavenier 외, "메모리 내 프로세서 아키텍처의 변형 호출 병렬화", BIBM, 2020. 라서 2D 점수 행렬의 크기는 DPU 수에 따라 2차적으로 증가합니다. 그림 19
는 (a) NW의 전체 실행(모든 반복 포함) 및 (b) 가장 긴 대각선만 실행한 약
[297] V. Zois et al., "프로세싱을 위한 대규모 병렬 스카이라인 계산"
한 스케일링 결과를 보여줍니다.
메모리 아키텍처”, PACT, 2018.
[298] J. Nider 외, "스토리지 클래스 메모리 처리", HotStorage, 2020.
[299] C. Giannoula 등, "SparseP: 실제 메모리 내 처리 시스템에서 효율적인 희소 행렬 벡터 곱셈을 향하
여", arXiv 사전 인쇄 arXiv:2201.05072,
2022. 그림 19에서 두 가지 관찰을 수행합니다. 첫째, 문제의 크기(2D 점수 행렬)
[300] H. Shin 등, "McDRAM: DRAM의 낮은 대기 시간 및 에너지 효율적인 매트릭스 계산", IEEE TCADICS, 가 2차적 으로 증가하므로 전체 실행(그림 19a)에 대한 DPU의 실행 시간은
2018.
DPU 수에 따라 증가합니다 . 우리는 섹션 5.1.2에서도 동일한 관찰을 합니
[301] S. Cho 외, "McDRAM v2: 엣지 의 심층 신경망에서 대형 모델 문제를 해결하기 위한 동적 랜덤 액세스
메모리 시스톨릭 어레이 가속기 ", IEEE Access, 2020. 다 . 둘째, 가장 긴 대각선에 대한 DPU의 실행 시간(그림 19b)은 DPU 수가
증가함에 따라 일정하게 유지됩니다. 그 이유는 가장 긴 대각선의 길이가 시퀀
[302] J. Gómez‑Luna 등, "메모리 중심 컴퓨팅 시스템 벤치마킹: 실제 메모리 내 처리 하드웨어 분석", IGSC,
스 길이와 DPU 개수에 따라 선형적으로 증가하기 때문입니다. 결과적으로 가
2021.
[303] S. Che 외, "Rodinia: 이기종 컴퓨팅을 위한 벤치마크 제품군", 장 긴 대각선에 대해 선형 약한 스케일링이 관찰됩니다.
IISWC, 2009.

9 부록 이러한 결과는 (1) 2D 점수 행렬의 가장 긴 대각선 계산에서 더 많은 수의

이 부록은 마이크로 벤치마크 중 하나(섹션 9.1)와 네 가지 PrIM 벤치마크(섹
션 9.2)에 대한 몇 가지 추가 결과를 제시합니다. 섹션 9.3 에는 PrIM 벤치마크
의 CPU 및 GPU 버전 소스가 나와 있습니다 .
9.1 산술 처리량과 태스크릿 수
그림 18은 다양한 운영 강도에서 다양한 태스크릿 수에 대한 산술 처리량 결
과를 보여줍니다 . 이 그림은 다양한 작업 강도 에 대한 산술 처리량의 변화를
보여주기 위한 목적으로 그림 9에 제시된 실험 결과의 다른 관점을 보여줍니다 .
우리는 그림 18에서 두 가지 주요 관찰을 수행합니다.
첫째, 모든 데이터 유형 및 작업에 대해 가능한 가장 높은 처리량은 11개의
태스크릿, 즉 파이프라인을 완전히 활용하는 태스크릿 수에서 달성됩니다 . 그
러나 최고 처리량 값 에 도달하는 작업 강도는 실제 데이터 유형 및 작업에 따
라 달라집니다. 예를 들어, 32비트 정수 추가의 최고 처리량은 OP/B, 즉 32비
트 요소당 1개의 추가에서 달성됩니다. 부동 소수점 곱셈의 경우 OP/B에서 가
장 높은 처리량, 즉 32개의 32비트 요소 마다 1개의1 4곱셈이 달성됩니다 .
1 128
활성 DPU가 NW에 더 유익하다는 것과 (2) 전체 NW에 대해 선형 스케일링
을 관찰하지 않는 이유를 보여줍니다.
9.2.2 이미지 히스토그램. 두 가지 버전의 히스토그램(HST‑S, HST‑L)에 대
해 다양한 히스토그램 크기에 대한 결과를 제시합니다 . 그림 20은 64에서
4096 사이의 히스토그램 크기에 대한 실행 시간 결과를 보여줍니다. 입력은
표 3에 지정된 것으로 12비트 깊이의 이미지입니다(따라서 최대 히스토그램 크
기는 4096입니다).
결과는 64개에서 1024개 빈 사이의 히스토그램에 대해 HST‑S가 HST‑L보
다 1.6 ‑ 2.5배 더 빠르다는 것을 보여줍니다. 히스토그램 크기를 늘리면 DPU
에서 실행할 수 있는 태스크릿 수가 줄어들기 때문에 HST‑S 의 성능이 저하됩
니다. 예를 들어 , 512개 빈의 경우 WRAM의 양이 제한되어 있기 때문에 8개
의 태스크릿만 시작할 수 있습니다(각 태스크릿에는 자체 로컬 히스토그램이
있음).
4046개 저장소의 경우 HST‑S는 2개의 태스크릿만 실행할 수 있습니다. 2048개
의 bin 이후에는 실행 시간이 히스토그램 크기와 무관하므로 HST‑L의 성능이 더
빨라집니다 .
9.2.3 감소. 섹션 4.12에서 소개한 RED의 세 가지 버전을 비교합니
다. RED에는 두 단계가 있다는 것을 기억하세요. 첫 번째 단계에서
각 태스크릿은 입력 배열의 할당된 청크 값을 누적합니다 . 두 번째 단
계에서 RED는 모든 태스크릿의 로컬 합계에 대한 최종 축소를 수행합
니다 . 세 가지의 차이점

35
Machine Translated by Google

64.00 64.00
(a) INT32, ADD (1 DPU) 8 8
(b) INT32, MUL (1 DPU)
32.00 4 32.00 4
16.00 2 16.00 2
1 1
8.00 8.00
1/2 1/2
4.00 4.00
1/4 1/4
2.00 1/8 2.00 1/8
1.00 1/16 1.00 1/16
1/32 1/32
0.50 0.50
1/64 1/64
0.25 0.25
1/128 1/128
량(
리
처
술
산
일
케
스
그
로

량(
리
처
술
산
일
케
스
그
로
0.13 0.13
,SPO)M

,SPO)M
1/256 1/256
0.06 1/512 0.06 1/512
1/1024 1/1024
0.03 0.03
1 2 345678 9 10 11 12 13 14 15 16 1/2048 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 1/2048

#태스크렛 #태스크렛

64.00 64.00
(c) FLOAT, ADD (1 DPU) 8 (d) FLOAT, MUL (1 DPU) 8
32.00 4 32.00 4
16.00 2 16.00 2

8.00 1 8.00 1
1/2 1/2
4.00 4.00
1/4 1/4
2.00 2.00
1/8 1/8
1.00 1/16 1.00 1/16

0.50 1/32 0.50 1/32

1/64 1/64
0.25 0.25
1/128 1/128
량(
리
처
술
산
일
케
스
그
로

량(
리
처
술
산
일
케
스
그
로

0.13 0.13
,SPO)M

,SPO)M

1/256 1/256
0.06 1/512 0.06 1/512
0.03 1/1024 0.03 1/1024
1 2 345678 9 10 11 12 13 14 15 16 1/2048 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 1/2048
#태스크렛 #태스크렛

그림 18: (a) 32비트 정수 추가, (b) 32비트 정수 곱셈, (c) 32비트 부동 소수점 추가 및 (d) 32비트 부동의 다양한 작업 강도에 대한 산술 처리량 대 태스크릿 수 포인
트 곱셈. 범례는 작동 강도 값(OP/B)을 보여줍니다. y축은 로그 스케일입니다.

20000 250 800

DPU‑CPU DPU‑CPU
18000 700 HST‑L HST‑S
CPU‑DPU CPU‑DPU
16000 200
DPU 간 DPU 간 600
14000
DPU DPU 500
12000 150
400
10000
300
8000 100
시
행
실
간(
)sm
시
행
실
간(

시
행
실
간(

200
)sm

)sm

6000
4000 50 100
2000 0
1

1
4

4
61

61
46

46

0 0 64 128 256 512 1024 2048년 4096

히스토그램 크기(빈)
(ㅏ) #DPU (비) #DPU

그림 20: 1 DPU에서 두 가지 버전의 히스토그램(HST‑L, HST‑S)의 실행 시간

그림 19: NW의 약한 스케일링 평가: (a) NW의 완전한 실행, (b) 가장 긴 대각
(ms)입니다.
선의 실행.

하나의 DPU에서 2~16개의 태스크릿에 대해 순차(SINGLE) 또는 병렬 트리

버전은 두 번째 단계가 구현되는 방식에 있습니다. 첫 번째 버전은 단일 tasklet을 사용하 기반(BARRIER, HANDS) 축소를 수행하는 데 필요합니다 .
여 두 번째 단계에서 순차적 축소를 수행합니다(그림 21~23의 SINGLE). 다른 두 버전은 우리는 세 가지 버전 중 가장 효율적인 버전은 다음과 같습니다.
두 번째 단계에서 병렬 트리 기반 축소를 구현합니다( 섹션 4.12 참조). 다른 두 버전 간의 순차적 축소(SINGLE). 그러나 핸드셰이크(HANDS)를 사용하는 트리 기반 버전보다 몇
유일한 차이점은 각 트리 수준의 끝에서 동기화에 사용되는 동기화 프리미티브입니다 . (1) 주기 더 빠릅니다(16개의 태스크릿으로 6% 더 빠름) . 우리는 또한 태스크렛의 수가 증가
모든 태스크릿에 대한 장벽(그림 21~23의 BARRIER) 또는 (2) 태스크릿 쌍 간의 핸드셰 할 때 장벽의 높은 비용을 관찰합니다 . 이 결과는
이크 (그림 21~23의 손). 그림 21은 실행 주기 수를 보여줍니다.
동기화 프리미티브는 UPMEM PIM 아키텍처의 현재 구현에 높은 오버헤드를
부과합니다 . 그럼에도 불구하고, 최종 감소의 상대적 가중치는 입력이 있을
때 무시할 수 있습니다.

36
Machine Translated by Google

16000
13760 SCAN‑SSA의 "Add", SCAN‑ RSS의 "DPU Reduction" + "DPU Scan")
12000

8000
및 호스트 CPU의 중간 스캔("Inter‑DPU")을 추가합니다.
4996
4000 1776년 2499 2654
528 576 768 1072 1392
기
주
행
실

288 304
0
유
소 1.4 6

유
소

유
소

유
소
의
나
하

의
나
하

의
나
하

의
나
하
DPU 간
벽
장

벽
장

벽
장

벽
장
1.2 DPU 스캔 5

나무 나무 나무 나무 1 DPU 추가/감소
4
2 4 8 16 0.8
삼
축소 버전(단일 태스크릿, 장벽 포함, 악수 포함) 0.6
#태스크렛
2
0.4

간(
시
행
실

간(
시
행
실
)sm

)sm
0.2 1
그림 21: 두 번째 단계에서 순차적 축소(SINGLE) 대 병렬 트리 기반 축소(BARRIER,
HANDS)의 효과 0 0
SSA RSS SSA RSS SSA RSS SSA RSS SSA RSS
RED 벤치마크 단계입니다.
2048년 4096 8192 16384 65536
스캔 버전 스캔 버전
배열이 큽니다. 그림 22는 세 가지의 실행 주기를 보여줍니다. 배열 크기 배열 크기

2‑16개의 태스크릿이 있는 2K 64비트 요소의 입력 배열 버전

하나의 DPU에. 세 가지 버전의 차이는 매우 큽니다. 그림 24: 두 가지 버전의 스캔(SCAN‑SSA, SCAN‑RSS)
작지만 여전히 SINGLE이 약간 더 빠르다는 것을 알 수 있습니다(즉, 2% 1개의 DPU.

HANDS 이상, BARRIER 이상 47%).

1.2E+05 이 결과의 주요 관찰은 SCAN‑SSA가 실행된다는 것입니다.

1.0E+05 98200 98416 98265
8.0E+04 소규모 배열(2048‑8192)의 경우 더 빠릅니다. 커널 시간 및 Inter‑DPU 스캔
6.0E+04 50849 52011 51060
35036
4.0E+04 29196 32681 29412 23780 24334 SCAN‑SSA와 SCAN‑RSS의 시간은 매우 유사하지만
2.0E+04
작은 크기에서는 커널 추가가 축소 커널보다 빠릅니다. 그만큼
기
주
행
실

0.0E+00

그 이유는 Reduction 커널이 다음 작업의 오버헤드로 인해 부담을 받기 때문입니다.

유
소

유
소

유
소

유
소
의
나
하

의
나
하

의
나
하

의
나
하
벽
장

벽
장

벽
장

벽
장

DPU 내 동기화(장벽) 및 최종 감소, 여기서

나무 나무 나무 나무 하나의 태스크릿만 작동합니다. 이 오버헤드는 다음에 대해 무시할 수 있습니다.
2 4 8 16 더 큰 배열. 결과적으로 SCAN‑RSS는 대규모 배열의 경우 더 빠릅니다(더
축소 버전(단일 태스크릿, 장벽 포함, 악수 포함) 16384개 요소보다).
#태스크렛

9.3 벤치마크의 CPU 및 GPU 버전

그림 22: 세 가지 버전의 축소 실행 주기
1개의 DPU에 2K 64비트 요소가 있습니다. 표 5는 PrIM의 CPU 및 GPU 버전의 소스를 보여줍니다.
섹션 5.2에서 비교 목적으로 사용하는 벤치마크입니다.
2M 64비트 요소 배열(그림 23)의 경우 우리는 PrIM 벤치 마크 제품군[214] 의 일부로 이러한 CPU 및 GPU 버전을 제공합니다 .

세 가지 버전의 성능은 완전히 무시할 수 있습니다.

대부분의 실행 주기는 RED의 첫 번째 단계에서 소비됩니다.
표 5: PrIM 벤치마크의 CPU 및 GPU 버전.
1.2E+08
9.9E+07 9.9E+07 9.9E+07
1.0E+08
8.0E+07
벤치마크 CPU 버전 GPU 버전
6.0E+07 5.0E+07 5.0E+07 5.0E+07
4.0E+07 2.5E+07 2.5E+07 2.5E+07
1.7E+07 1.7E+07 1.7E+07
버지니아
OpenMP(사용자 정의) CUDA SDK [282]
2.0E+07
기
주
행
실

0.0E+00 GEMV OpenMP(사용자 정의) CUDA(사용자 정의)

유
소

유
소

유
소

유
소
의
나
하

의
나
하

의
나
하

의
나
하

SpMV OpenMP(사용자 정의) CUDA(사용자 정의)

벽
장

벽
장

벽
장

벽
장

SEL DS 알고리즘 [250] DS 알고리즘 [250]

나무 나무 나무 나무
유니 DS 알고리즘 [250] DS 알고리즘 [250]
2 4 8 16
학사 OpenMP(사용자 정의) CUDA(사용자 정의)
축소 버전(단일 태스크릿, 장벽 포함, 악수 포함)
#태스크렛 TS [254] [254]
BFS OpenMP(사용자 정의) CUDA [256]
그림 23: 세 가지 버전의 축소 실행 주기 북서쪽 로디니아 [303] 로디니아 [303]
1개의 DPU에 2M 64비트 요소.
MLP OpenMP(사용자 정의) CUDA(사용자 정의)
HST 차이 [287] 차이 [287]
9.2.4 접두사 합계(스캔). 우리는 두 가지의 실행 시간을 비교합니다 빨간색 스러스트 [283] 스러스트 [283]
다양한 배열 크기에 대한 스캔 버전, SCAN‑SSA 및 SCAN‑RSS 주사 스러스트 [283] 스러스트 [283]
(2048, 4096, 8192, 16384, 65536 요소)가 DPU에 있습니다. 그림 24 TRNS [270] [270]
실행 시간 결과를 보여줍니다. 두 버전 모두 그림은
DPU 커널 시간 분석을 보여줍니다("DPU 스캔" + "DPU

37
Machine Translated by Google

Juan Gómez‑Luna는 SAFARI Re‑의 수석 연구 그래프 처리, 포인터 추적 데이터 구조, 기계 등 새로운 애플리케이션의 하드웨
원이자 강사입니다. 어/소프트웨어 공동 설계에 대해 설명합니다.
그룹 @ ETH Zürich를 검색하세요. 그는 2001년 스 대규모 멀티코어 시스템 및 근거리 데이터와 같은 최신 컴퓨팅 패러다임을 사용하
페인 세비야 대학교 에서 통신 공학 학사 및 석사 학위 여 워크로드 및 희소 선형 대수학을 학습합니다.
를 받았으며 , 처리 아키텍처. 그녀는 ACM, ACM‑W 및
그리스 기술 회의소.
컴퓨터 과학 박사 학위
Geraldo F. Oliveira는 학사 학위를 받았습니다.
2012년 스페인 코르도바 대학교.
브라질 비코사 연방 비코사 대학교 에서 컴퓨터
2005년부터 2017년까지 그는 코르도바 대학교의 교수로 재직했습니다. 그의 연구 관심
공학 학위를 받았습니다 .
분야는 메모리 내 처리, 메모리 시스템, 이기종 컴퓨팅, 의료 영상 및 생물정보학의 하드웨
2015년에 컴퓨터 석사 학위를 취득했습니다.
어 및 소프트웨어 가속에 중점을 두고 있습니다. 그는 최초의 공개 벤치마크인
연방 대학교의 과학
PrIM(https://github.com/CMU‑SAFARI/prim‑benchmarks)의 주요 저자입니다.
리오그란지두술, 포르투알레그레, 브라질,
2017년. 2018년부터 활동 중이다.
박사 학위를 향해 Onur Mutlu 학위
실제 메모리 내 처리 아키텍처를 위한 제품군 및 Chai
스위스 취리히 소재 ETH 취리히에서. 그의
(https://github.com/chai‑benchmarks/chai), 벤치마크 제품군
현재 연구 관심 분야에는 시스템이 포함됩니다.
CPU/GPU/FPGA를 갖춘 이기종 시스템.
메모리 내 처리 지원 및
Izzat El Hajj 는 조교수입니다 메모리를 사용한 처리 아키텍처, 데이터 중심 가속기
컴퓨터공학과에서 신흥 애플리케이션, 근사 컴퓨팅 및 신흥을 위한
베이루트 아메리칸 대학교에서. 그 소비자 장치용 메모리 시스템. 그는 여러 출판물을 가지고 있습니다.
석사 및 박사 학위를 받았습니다. 전기에서 이 주제에 대해.
2018년 Cal 및 컴퓨터 공학
Onur Mutlu 는 ETH Zurich의 컴퓨터 과학 교수
일리노이 대학교 어바나‑샴페인 캠퍼스에서 Dan
입니다 . 그는 또한
학위를 받았습니다.
카네기 멜론 대학교 교수
Vivoli 기증 펠로십. 그 이전에,
그는 전기 및 공학 학사 학위를 받았습니다. 그가 이전에 재직했던 대학교
Strecker 조기 경력 교수직. 그의
2011년부터 컴퓨터공학과 현재 더 폭넓은 연구 관심 분야는
베이루트 아메리칸 대학교(American University of Beirut)
컴퓨터 아키텍처, 시스템, 하드웨어 보안 및 생
우수졸업생상을 받았습니다. 그의 연구 관심 분야 는 애플리케이션 가속화 및 프로그래밍
물정보학 분야. 그는 자신의 다양한 기술과 함
지원입니다.
께
특별한 관심을 갖고 있는 신흥 가속기와 추억
그룹 및 공동 작업자가 발명했습니다.
GPU 및 메모리 내 처리.
수년에 걸쳐 산업에 영향을 미쳤으며 상업용 마이크로
Ivan Fernandez는 학사 학위를 받았습니다. 프로세서 및
컴퓨터 공학과 그의 동의 메모리/스토리지 시스템. 그는 ECE에서 박사 학위와 석사 학위를 취득했습니다.
메카트로닉스 공학 석사 학위 텍사스 대학교 오스틴에서 학사 학위를 취득하고 앤아버 미시간 대학교에서 컴퓨터 공학
2017년 말라가대학교에서 및 심리학 학사 학위를 취득했습니다. 그는 컴퓨터 아키텍처 그룹을 시작했습니다.
각각 2018. 그는 현재 박사과정을 밟고 있습니다. 말
라가 대학교에서 학위를 취득했습니다. 그의 현재 연구 Microsoft Research(2006‑2009), Intel Corporation, Advanced Micro Devices,

관심에는 기억 처리가 포함됩니다. VM웨어와 구글. 그는 IEEE 고성능상을 받았습니다.

근거리 데이터 처리, 스택 메모리 IEEE 컴퓨터 시간 상, 컴퓨터 아키텍처 테스트
아키텍처, 고성능 컴퓨팅 , 초정밀 컴퓨팅 및 시간 ACM 협회 Edward J. McCluskey 기술 공로상
첫 번째 IEEE 컴퓨터상인 SIGARCH Maurice Wilkes Award
계열 분석. 제1회 인텔 얼리 소사이어티 젊은 컴퓨터 아키텍트 상(Society Young Computer Architect Award)

크리스티나 지아눌라 크리스티나 지‑

미국 국립과학재단 커리어 교수상 CAREER
Carnegie Mellon University Ladd Research Award 교수상 수상
annoula는 박사 학위입니다. 학교에 다니는 학생
다양한 기업으로부터 파트너십 수상 및 건전한 숫자
전기 및 컴퓨터 공학과
다양한 컴퓨터에서 최우수 논문 또는 "Top Pick" 논문 인정
국립 기술 대학의
시스템, 아키텍처 및 보안 장소. 그는 ACM 펠로우입니다.
아테네. 그녀는 대학 에서 전기 및 컴퓨터
IEEE 펠로우이자 유럽 아카데미의 선출 회원
공학 학위를 받았습니다. (아카데미아 유로파에아). 그의 컴퓨터 아키텍처와 디지털 논리
2016년 NTUA, 상위 2%로 졸업
그녀의 수업 중. 그녀의 연구 관심 분야는 다음과 같습니다.
디자인 강좌 강의 및 자료는 유튜브에서 무료로 보실 수 있습니다
(https://www.youtube.com/OnurMutluLectures) 및 그의 연구
컴퓨터 아키텍처의 교차점
그룹은 다양한 소프트웨어 및 하드웨어 제품을 만듭니다.
그리고 고성능 컴퓨팅. 특히, 그녀의 연구 초점은

38
Machine Translated by Google

온라인(https://safari.ethz.ch/)에서 무료로 이용 가능합니다. 자세한 내용은

그의 웹페이지 https://people.inf.ethz.ch/omutlu/를 참조하십시오.

39