ISCA 2026 · Zerva, Eleftherakis, Maras et al. (National Technical University of Athens) · DOI 10.1109/ISCA66397.2026.00111

sCROOGe: RISC-V GPU(Vortex) 에 out-of-order 실행을 RTL 로 직접 만들어, simulator 가 놓친 성능·면적·전력·timing 을 다시 재기

원문 papers/sCROOGeː_Circuit-level_Design_and_Optimization_Framework_for_RISC-V_Out-of-Order_GPUs.pdf (17쪽, 본문 13쪽 + appendix·참고문헌) · §V-C p.6 = 논문이 그렇게 쓴 절·쪽 · 해석 = 논문 내용에서 요약자가 끌어낸 설명 · 논문에 없음 = 배경지식·예시 · 용어는 1 절 용어표의 뜻으로만 쓴다 · 그림은 누르면 크게 열린다

0한눈에 보기

GPU 는 warp 를 바꿔 가며 stall 을 숨기는데(TLP), 동시에 돌릴 warp 가 부족한 workload 는 stall 이 그대로 드러난다. 그래서 한 warp 안에서 독립 명령어를 먼저 실행하는 out-of-order(OoO) GPU 가 제안돼 왔지만 모두 software simulator 로만 평가됐다 §I p.1.
이 논문은 frontend OoO(Issue stage)와 backend OoO(Operand Collect stage)를 open-source RISC-V GPU 인 Vortex 에 합성 가능한 RTL 로 처음 구현하고, ASIC synthesis 로 성능·면적·전력·timing 을 다시 쟀다 Abstract p.1.

0.1

0.1.1기 상황

GPU 는 한 warp 가 기다리면 다른 warp 로 바꿔 실행해 stall 을 숨긴다. 일반 연산 workload 중에는 동시 warp 가 부족해 stall 이 잦은 것이 많고, warp 를 늘리면 cache 경합이 생긴다 §I p.1.

0.1.2승 문제

LOOG·GhOST·SIMIL 같은 OoO GPU 는 simulator 로만 평가됐다. Accel-Sim 은 실제 V100 대비 cycle 오차(MAPE)가 11.55% 이고, simulator 기반 연구는 OoO 의 IPC 이득을 크게, 면적·전력 overhead 를 작게 보고했다 §II p.2–3.

0.1.3전 기법

Vortex pipeline 에 frontend OoO(Issue Buffer + Dependence Checker)와 backend OoO(Collector Unit + RAT + RRS)를 SystemVerilog 로 만들고, UUID 순환 재사용·broadcast pipelining·scoreboard 제거 등 RTL 에서만 보이는 최적화를 넣었다 §V–VI p.5–8.

0.1.4결 결과

GF 22nm synthesis 에서 두 OoO 모두 baseline 과 같은 1 GHz 로 동작한다. 같은 면적의 in-order SM(warp 를 늘린 것) 대비 backend OoO 가 IPC 평균 14.4% 높고, 16 warp 구성에서 EDP 가 최대 27.9% 개선됐다 §VII-C·E·F p.9–12.

0.2

0.2.cOoO 실행은 stall 된 명령어 뒤의 독립 명령어를 먼저 실행해 한 warp 안의 ILP 를 쓴다. 이 논문은 이 아이디어 자체가 아니라, 그것을 GPU pipeline 에 실제 회로로 넣었을 때의 비용과 이득을 잰다 §I p.1. 명령어 예시는 요약자가 만든 것이다 논문에 없음.

0.3

0.3.1

11.55%

Accel-Sim 의 cycle MAPE (V100 실측 대비, Rodinia·Deepbench)

0.3.2

+14.4%

IPC, 같은 면적 in-order SM(warp 2배) 대비 backend OoO 평균 (Table IV)

0.3.3

−27.9%

EDP 최대 개선, backend OoO 16 warp 구성 (Fig.23)

0.3.4

1 GHz

baseline·두 OoO 모두 같은 최대 주파수 (22nm synthesis, Table III)

1배경: GPU pipeline, 의존성, RTL 평가

GPU 의 SM 은 warp 단위로 명령어를 순서대로(in-order) 내보내고, register 의존성(hazard)이 풀릴 때까지 그 warp 를 멈춘다. OoO 는 이 순서를 깨되 결과가 같도록 hazard 를 추적해야 한다 §IV p.4–5.
이 논문의 주장은 그 추적 회로의 비용(면적·전력·critical path)은 RTL 을 합성해 봐야 정확히 보인다는 것이다 §II p.2–3.

1.1용어표

1.1.1

용어	정확한 뜻 (이 요약에서)	기호	논문 원문 표기
1.1.1.1warp · thread	warp = 같은 명령어를 함께 실행하는 thread 묶음. thread 수 = warp 하나의 폭(SIMD width)	W, T	"warps", "threads per warp". 구성은 (W, T) 로 적는다. 예 (32,4) = 32 warp × warp 당 4 thread
1.1.1.2SM (Vortex core)	warp scheduler·pipeline·register file·L1 을 가진 실행 단위 하나. 평가는 processing block 1 개, L1 16 KB 의 SM 하나	–	"SM", "core" 혼용 (§VII-A p.8)
1.1.1.3TLP · ILP	TLP = 동시에 실행 가능한 warp 수에서 오는 병렬성. ILP = 한 warp 의 명령어 열 안에서 서로 독립인 명령어의 병렬성	–	"Thread-Level Parallelism", "Instruction-Level Parallelism"
1.1.1.4OoO	앞 명령어가 stall 일 때 뒤의 독립 명령어를 먼저 실행하는 방식. 이 논문은 warp 안의 명령어 순서를 바꾼다	–	"Out-of-Order (OoO) execution", "instruction reordering"
1.1.1.5frontend OoO	Issue stage 에서 순서를 바꾸는 방식. GhOST·SIMIL 계열. Issue Buffer + Dependence Checker 로 구현	–	"frontend-based OoO". CPU 의 fetch/decode frontend 와 다른 뜻이다
1.1.1.6backend OoO	Operand Collect(OC) stage 에서 순서를 바꾸는 방식. LOOG 계열. Collector Unit + RAT + RRS 로 구현	–	"backend-based OoO"
1.1.1.7baseline	수정하지 않은 in-order Vortex SM	–	"baseline Vortex"
1.1.1.8CU (Collector Unit)	OC stage 에서 명령어 하나의 operand 를 모으는 slot. backend OoO 에서는 reservation station 역할	N	"Collector Units (CUs)". compute unit(AMD) 과 다른 뜻이다
1.1.1.9IsB (Issue Buffer)	frontend OoO 에서 decode 된 명령어를 담아 두고 독립인 것을 고르는 buffer. entry 수가 reordering 깊이	–	"Issue Buffer (IsB)"
1.1.1.10InFl (In-Flight buffer)	frontend OoO 에서 이미 issue 됐고 writeback 전인 명령어의 destination register 를 기록하는 buffer	–	"In-Flight buffer (InFL)". 원문 표기가 InFL·InFl 로 섞인다
1.1.1.11RAT	register 마다 "값을 RF 에서 읽을지, 어느 RRS entry 의 broadcast 를 기다릴지" 를 적은 표	–	"Register Alias Table"
1.1.1.12RRS	backend OoO 에서 writeback 을 기다리는 명령어의 이름표(ID)와 결과 임시 저장 칸. CU 를 일찍 풀어 주려고 둔다	R	"Register Renaming Stack"
1.1.1.13UUID	warp 마다 증가하는 명령어 순번. 원래 program order 를 기억해 commit·memory 순서를 지킨다	N bit	§V-A 는 "Universal Unique Identification", §I 은 "unique instruction identifiers" 라 쓴다
1.1.1.14scoreboard	baseline 이 쓰는, 쓰기 대기 중인 register 표. 의존 명령어를 멈춘다	–	"scoreboard"
1.1.1.15IPC	cycle 당 실행한 warp 명령어 수. 같은 주파수일 때 성능 비교 지표	–	"Instructions Per Cycle". 원문 "speedup", "IPC gain", "IPC Delta" 는 모두 baseline 대비 IPC 증가율
1.1.1.16RTL · synthesis · PnR	RTL = 회로를 register 와 논리로 적은 HDL 코드. synthesis = RTL 을 표준 cell 회로로 바꾸기. PnR = 그 cell 을 칩 위에 배치·배선하기	–	"Register Transfer Level", "logic synthesis", "Place-and-Route"
1.1.1.17PPA · ADP · EDP	PPA = 성능·전력·면적. ADP = 면적 × 실행시간, EDP = 에너지 × 실행시간. 둘 다 작을수록 좋다	–	"Area-Delay Product", "Energy-Delay Product" (§VII-F p.12)
1.1.1.18iso-area	면적을 같게 맞춘 비교. 이 논문은 OoO SM 과 "warp 수를 2배로 늘린 in-order SM" 을 비교한다	–	"iso-area" (Table IV)

1.2Vortex 의 6 단 pipeline 과 OoO 가 끼어드는 자리

1.2.1

baseline Vortex stagefrontend OoO 부품backend OoO 부품

1.2.1.cbaseline Vortex 는 Schedule·Fetch·Decode·Issue·Execute·Commit 6 단이고, Issue stage 안에 IBuffer·scoreboard·Operand Collector 가 있다 §IV p.5. 두 OoO 방식은 모두 Issue stage 안을 바꾼다. 차이는 순서를 바꾸는 위치다 §III p.4. 그림은 Fig.2 를 줄여 다시 그린 것이다 논문에 없음.

1.3hazard 세 종류와 register renaming

1.3.1

1.3.1.cRAW 는 진짜 데이터 의존이라 반드시 기다려야 한다. WAR·WAW 는 같은 register 이름을 재사용해서 생기는 가짜 의존이라, 이름을 바꾸면(renaming) 없앨 수 있다. backend OoO 는 RAT + RRS 로 renaming 을 하고, frontend OoO 는 renaming 없이 Dependence Checker 로 세 hazard 를 모두 검사한다 §V-B·C p.5–6. 명령어 예시는 요약자가 만든 것이다 논문에 없음.

1.4simulator 와 RTL 평가의 차이

1.4.1

1.4.1.csimulator 는 component 동작을 C++ 로 추상화하고 microbenchmark 로 보정한다 §II p.2. 면적은 CPU template 에서 외삽한 McPAT 변형, 전력은 AccelWattch 로 추정한다 §II p.3. sCROOGe 는 RTL 을 Verilator 로 cycle 단위 실행하고, Synopsys Design Compiler 로 GF 22nm 에 합성해 면적·전력·timing 을 얻으며, 일부 구성은 Cadence Innovus PnR 로 다시 확인한다 §VII-A·G p.8·12 Appendix H p.14.

1.4.2

SIMT · warp scheduling

GPU 는 thread 여러 개를 warp 로 묶어 한 명령어로 함께 실행한다(SIMT). warp scheduler 는 매 cycle 실행 가능한 warp 하나를 골라 명령어를 낸다. NVIDIA Volta·Ampere·Blackwell 도 sub-core 당 cycle 마다 warp 명령어 하나만 schedule 한다 §I p.1.OoO 는 warp 를 더 늘리지 않고 한 warp 의 명령어 순서를 바꿔 stall 을 줄이는 대안이다.

Tomasulo · reservation station

CPU OoO 의 고전 방식으로, 명령어를 reservation station 에 두고 operand 가 broadcast 로 도착하면 실행한다 논문에 없음. LOOG 는 CU 를 reservation station 으로 썼다 §V-C p.6.sCROOGe backend 는 CU 를 dispatch 직후 풀고, writeback 대기는 작은 RRS entry 가 맡는다.

critical path · 최대 주파수

한 cycle 안에 신호가 지나야 하는 가장 긴 논리 경로다. 이 경로 지연이 clock 주기를 정한다 논문에 없음. sCROOGe 에서 global critical path 는 Execute stage 993 ps 다 Table III p.9.OoO 회로가 Issue stage 경로를 늘려도 993 ps 를 넘지 않으면 주파수는 그대로이고, IPC 만으로 성능을 비교할 수 있다.

Vortex

RISC-V ISA 를 확장한 open-source soft GPGPU 다. 전부 합성 가능한 Verilog 이고, SM 수·cache·FU 수 등을 설정할 수 있다. 소프트웨어는 POCL(OpenCL)·LLVM 을 쓴다 §IV p.4 §VII-A p.8.sCROOGe 는 Vortex 위에 두 OoO 방식을 얹은 framework 다.

2문제: simulator 는 OoO GPU 의 이득은 크게, 비용은 작게 보았다

Accel-Sim 은 실제 V100 대비 per-kernel cycle 오차가 평균 11.55%, Deepbench 는 30% 초과, GRU RNN inference 는 73% 다 §II p.2.
64 warp × 32 thread 에서 sCROOGe RTL 로 잰 IPC 이득은 backend 4.18%, frontend 0.86% 로, simulator 기반 원 논문 보고치(23%·6.9%·31%)보다 훨씬 작고 면적·전력 overhead 는 더 크다 Table II p.3.

Fig.1 — 2.1.cFig. 1: Simulated vs Hardware-measured cycles per-kernel on the Rodinia-3.1 and Deepbench benchmark suites. (p.2) 점 하나는 kernel 하나이고, x 축은 Accel-Sim 이 예측한 cycle, y 축은 V100 에서 잰 cycle 이다(둘 다 log). 점이 대각선에서 벗어난 만큼이 오차다. 논문은 이 오차가 C++ 추상화 수준에서 component 를 모델링하는 한계에서 온다고 쓰고, 그래서 이후 평가를 RTL cycle-accurate model 로 한다고 밝힌다 §II p.2.

Table II — 2.2.cTABLE II: Overhead/Gain Comparison of sCROOGe vs SoTA OoO schemes reported results (64 warps, 32 threads). (p.3) 왼쪽 세 열은 LOOG·GhOST·SIMIL 원 논문이 simulator 로 보고한 값, 오른쪽 두 열은 sCROOGe RTL 에서 잰 값이다. 같은 자원 구성(64 warp, 32 thread)에서 RTL 의 IPC 이득은 작고, LOOG 의 면적, GhOST 의 면적·전력 overhead 는 크게 나온다. 논문은 frontend 의 IPC 이득 0.86% 가 오차 범위 안이라고 쓴다 §II p.3.

simulator 가 틀리는 이유 (논문 설명)

2.3

2.3.1면적: GPUWattch 의 McPAT 변형은 CPU template 에서 GPU 면적을 외삽하고 최신 공정으로 정규화하지 못해, 새 micro-architecture 평가에는 부정확하다 §II p.3.
2.3.2전력: AccelWattch 의 SASS 모드는 세밀한 구조 변경을 잡지 못하고, 추가 부품을 일부만 합성해 공정 정규화하므로 실제 연결·크기를 반영하지 못한다 §II p.3.
2.3.3예: LOOG 의 simulator 분석은 CU 32→48 확장 비용을 면적 2.57%, 전력 1% 미만으로 봤지만, sCROOGe 는 CU 8→12 에서 면적 10.3%, 전력 10.4% 를 쟀다 §II p.3.
2.3.4timing: OoO 구조는 critical path 를 늘리거나 바꾸고, 구조가 커질수록 interconnect 가 비선형으로 늘지만 simulator 는 이를 다루지 않는다 §II p.3.
2.3.5속도: RTL 을 FPGA 로 emulation 하면 수백 MHz 로 돌아 Accel-Sim(수 kHz)보다 빠르다고 논문은 쓴다 §II p.3. 다만 이 논문의 성능 측정은 Verilator RTL simulation 이며 전체 재현에 단일 process 로 약 270 시간이 든다 Appendix B p.14.

3기법: sCROOGe 의 두 OoO 방식과 RTL 최적화

두 방식 공통으로 UUID 생성기를 두어 원래 program order 를 기억한다. frontend OoO 는 Issue Buffer 에서 Dependence Checker 로 RAW·WAR·WAW 를 검사해 독립 명령어를 먼저 내보내고, backend OoO 는 CU 에서 RAT 로 renaming 해 operand 가 준비된 명령어를 먼저 dispatch 한다 §V p.5–7.
RTL 로 만들면서 broadcast 배선 축소, scoreboard 제거, LSQ 재평가 같은 설계 결정을 추가로 내렸다 §V-C·VI p.7–8.

Fig.2 — 3.0.1.cFig. 2: Baseline and modified Vortex pipeline. The blue components refer to the baseline, the green to the frontend-based and the orange to the backend-based sCROOGe scheme. Purple components are common between the two OoO schemes. (p.4) 파란 부품은 baseline Vortex, 초록은 frontend OoO(Issue Buffer·In-Flight Buffer·Dependence Checker), 주황은 backend OoO(RRS·RAT·Collector Units), 보라는 두 방식 공통(UUID generator)이다. 추가 부품이 모두 Issue stage 와 Schedule stage 에 모여 있어, Execute·memory 는 baseline 그대로라는 것을 보여 준다 §IV p.5 해석.

3.1① UUID: 짧은 순번을 순환해 쓰기

OoO 로 실행해도 commit 과 memory 순서를 맞추려면 각 명령어의 원래 순번이 필요하다. sCROOGe 는 warp 마다 오름차순 UUID 를 붙여 Commit stage 까지 함께 보낸다. 이 방식으로 fully associative reorder buffer 없이 순서를 지킨다고 논문은 쓴다 §V-A p.5.

3.1.1

3.1.1.cUUID 를 무한히 크게 두면 면적이 낭비되므로, warp ID 와 합쳐 짧은 UUID 를 순환해 쓴다. bit 폭이 $N$ 이면 serialization 오류 없이 $2^N - 2$ 개 명령어를 처리할 여유가 있다고 원문은 쓴다. 이를 넘으면 out-of-bounds flag 가 pipeline 을 멈춘다 §V-A p.5. 원형 배치 그림은 요약자가 그린 것이다 논문에 없음.

Fig.3 — out-of-bounds 검사 회로

3.2② frontend OoO: Issue Buffer 에서 독립 명령어 먼저

decode 된 명령어는 Issue Buffer(IsB)에 들어가고, Dependence Checker 가 IsB 와 In-Flight buffer(InFl)의 register 를 비교해 의존 bit-vector 를 만든다. Issue Arbiter 는 독립 명령어 중 IsB ID 가 가장 낮은 것을 고른다 §V-B p.5–6. RAW 는 rs 3 개를 InFl·IsB 의 모든 rd 와, WAW 는 rd 끼리, WAR 는 rd 를 IsB 의 rs 와만 비교한다. Issue 이후는 in-order 라 InFl 에서는 WAR 가 생기지 않기 때문이다 §V-B p.5.

Fig.5 — 3.2.1.cFig. 5: Frontend-based sCROOGe instruction flow. (p.6) ① IsB allocation arbiter 가 빈 IsB entry 와 UUID 범위를 확인해 명령어를 넣는다. ② 다음 cycle Dependence Checker 가 의존 bit 를 채운다. ③ Issue Arbiter 가 독립 명령어를 골라 scoreboard 로 보내고 ④ InFl entry 를 할당한다. ⑤~⑧ 은 baseline 과 같고, ⑨ writeback 이 끝나면(eop bit) InFl entry 를 비우고 관련 의존 bit 를 지운다 §V-B p.6. 메모리 명령어는 가장 오래된 것이 아니면 독립으로 보지 않는다 §V-B p.6.

Fig.4 — Dependence Checker 회로 · GhOST 와 다른 점

3.2.3

3.2.3.1GhOST 는 IBuffer 에서 IsB 로 in-order 로 옮기는 arbiter 를 두지만, sCROOGe 는 Fetch·Decode 처리량이 cycle 당 1 명령어라 decode 쪽 IBuffer 를 없앴다 §V-B p.5.
3.2.3.2GhOST 의 synchronization 제어 flag 도 Schedule stage 가 synchronization 을 처리하므로 필요 없다 §V-B p.5.

3.3③ backend OoO: CU 에서 operand 준비된 명령어 먼저

명령어는 순서대로 CU 에 들어간다. CU 는 RAT 를 보고 source register 를 RF 에서 읽을지, 어느 RRS entry 의 broadcast 를 기다릴지 정한다. operand 가 다 모인 CU 중 하나를 Dispatch Arbiter 가 매 cycle Execute 로 보내므로, 늦게 들어온 명령어가 먼저 실행될 수 있다 §V-C p.6–7. RAT 가 register 이름을 RRS ID 로 바꾸므로 WAR·WAW 가 사라지고, scoreboard stage 는 없앴다 §V-C p.6.

3.3.1

3.3.1.cLOOG 첫 판은 CU 를 Tomasulo 의 reservation station 으로 써서 writeback 까지 붙잡았고, CU 가 모자라 stall 이 늘었다. sCROOGe 는 RAT 에 CU ID 대신 RRS ID 를 적어, CU 를 dispatch 직후 풀고 writeback 대기는 RRS entry 가 맡게 한다 §V-C p.6. 32 warp·32 thread·CU 12 개 구성에서 CU 하나는 21.382 μm²(전체 0.9387 mm² 의 2.28%), RRS entry 하나는 0.873 μm²(0.09%)다 §V-C p.6. 막대 길이는 개념도다 논문에 없음.

Fig.7 — 3.3.2.cFig. 7: Backend-based sCROOGe instruction flow. (p.7) ① Allocation Arbiter 는 빈 CU, UUID 범위, writeback 자원(빈 RRS entry 또는 writeback 불필요) 세 조건을 확인한다. ② CU 가 RAT 를 읽어 renaming 된 source 를 복사하고 자기 RRS ID 를 RAT 의 rd 에 적는다. ③ RF 에서 읽을 operand 는 CU ID 가 낮은 순으로 RF 접근권을 받아 cycle 당 하나씩 읽는다. ④ operand 가 다 모이면 ready, ⑤ Dispatch Arbiter 가 매 cycle 하나를 ⑥ Execute 로 보낸다. ⑦ Commit 뒤 결과는 OC 로 돌아와 RRS entry 에 임시 저장되고 ⑨ 다음 cycle RF 에 쓰이며 기다리던 CU 들도 갱신된다 §V-C p.6–7.

Fig.6 — 3.3.3.cFig. 6: CDF of No-Available-CU stalls for backend sCROOGe. (p.7) x 축은 전체 cycle 중 "빈 CU 가 없어서" 생긴 stall 의 비율, y 축은 workload·SM 구성의 누적 분포다. CU 8 개에서 RRS 가 없으면 80% 의 application 이 이 stall 비율 42% 이상, RRS 12 entry 를 두면 23% 이상이다 §V-C p.6. 곡선이 왼쪽으로 옮겨 간 만큼 RRS 가 CU 부족 stall 을 줄였다는 그림이다.

Fig.8 · Fig.9 — writeback/broadcast 회로 · memory 명령어 reordering 을 뺀 이유

3.4④ RTL 에서 내린 최적화: broadcast 배선과 scoreboard 제거

backend OoO 는 RRS entry $R$ 개 각각이 CU $N$ 개의 rs 3 칸 모두에 결과를 보낼 수 있어야 하므로, warp 당 thread $T$ 개면 배선이 $3 \times N \times R \times T \times \text{datasize}$ 다. writeback 은 cycle 당 하나뿐이므로, sCROOGe 는 중간 result register 하나를 두어 배선을 $4 \times N \times T \times \text{datasize}$ 로 줄였다. 추가 cycle 은 writeback 에 이미 필요한 두 stage 안에 숨는다 §VI p.8.

3.4.1

$N$ = CU 수 · $R$ = RRS entry 수 · $T$ = warp 당 thread 수 · datasize = operand 하나의 bit 수

$$\begin{aligned} \text{before} &= 3 \times N \times R \times T \times \text{datasize} \\ \text{after} &= 4 \times N \times T \times \text{datasize} \end{aligned}$$§VI p.8

배선 수가 RRS entry 수 $R$ 에 비례하던 것이 $R$ 과 무관해진다. 비율은 $3R/4$ 이다 해석. CU 12 개 이상이면 같은 값을 담은 buffer 두 개로 CU 를 나눠 연결해 배선은 늘지만 부하와 timing path 가 짧아진다 §VI p.8.

3.4.2

계산기 논문에 없음 · datasize 는 32 bit 로 가정

CU 수 N RRS entry R thread T UUID bit N_u

frontend 최적화 — frontend OoO 에서 "per-warp oldest" 명령어를 고르면 그 명령어가 scoreboard 로 가서 의존 때문에 pipeline 을 멈추는 일이 잦았다. Issue Arbiter 에 독립 명령어만 주도록 바꾸자 IPC 가 2% 더 오르고, per-warp oldest buffer 와 scoreboard 의 SRAM 배열과 관련 논리를 없앨 수 있었다 §VI p.8. 논문은 이런 결정이 simulator 기반 연구에서는 고려되지 않았다고 쓴다 §VI p.8.

4구현

두 방식을 SystemVerilog 로 구현하고 Synopsys Design Compiler(v2022.12)로 GF 22nm FDSOI(TT, 0.9 V, 25°C)에 합성했다. RF·local memory·cache 는 GF Memory Compiler 의 SRAM macro 를 썼고, 전력은 gate-level simulation 의 VCD switching activity 를 PrimeTime 으로 분석했다 §VII-A p.8.
성능은 Verilator RTL simulation 으로 kernel 별 명령어·cycle 을 쟀고, 일부 구성은 Cadence Innovus(v23.11) PnR 과 IMEC N2(2nm) PDK 로 다시 확인했다 Appendix B·H p.14.

실험 구성 세부

4.1

항목	값	근거
4.1.1평가 단위	Vortex SM 1 개 (processing block 1 개, L1 16 KB). 수정이 SM 안에 한정되므로 GPU 전체로 확장된다고 논문은 쓴다	§VII-A p.8
4.1.2DRAM	Ramulator 연동	§VII-A p.8
4.1.3구성 범위	(warp, thread) = (4,4) ~ (64,32). NVIDIA 는 32·48·64 warp × 32 thread, embedded GPU 는 더 좁다	§VII-A p.8
4.1.4benchmark	Vortex framework 의 22 개 (OpenCL, POCL + LLVM) + ML 4 개(llama2-Gemm, CNN-Layer, Squeeze-Layer, llama-260k)	§VII-A p.8, §VII-C p.10–11
4.1.5synthesis 주파수	timing 분석은 최대 1 GHz, 면적·전력 DSE 는 400 MHz	§VII-C p.9, Fig.19
4.1.6PnR	Cadence, 400 MHz (22nm) · 1.2 GHz (2nm)	§VII-G·H p.12–13
4.1.7artifact	Zenodo 10.5281/zenodo.19453033, Docker, RAM 32 GB 초과, 성능 실험 단일 process 약 270 h	Appendix p.14
4.1.8공개 범위	RTL 전체 공개. 표준 cell·memory compiler 는 NDA 로 비공개, 면적·전력은 csv 로 제공	Appendix E·H p.14

5평가

두 OoO 모두 Issue stage critical path 가 늘지만 Execute stage(993 ps)를 넘지 않아 baseline 과 같은 1 GHz 로 동작하므로, 성능은 IPC 로 비교한다 §VII-C p.9. backend 가 모든 구성에서 frontend 보다 IPC 이득이 크고, (32,4) 에서 application 별 최대 27.3% 다 §I p.2 §VII-C p.9–10.
비용은 frontend 가 면적 최대 7.5%, 전력 8.2%, backend 가 28.6%, 32.1% 이고, 같은 면적의 in-order SM(warp 2배) 대비 backend 가 IPC 평균 14.4% 높다 §VII-E p.11–12.

Table III — 5.1.cTABLE III: Pipeline stage delays (psec) for the baseline and both sCROOGe schemes, synthesized at 1GHz frequency. (p.9) Issue stage 지연은 baseline 295 ps → frontend 600 ps → backend 901 ps 로 늘지만, 전역 critical path 는 세 설계 모두 Execute 993 ps 다. Commit→Issue result bus 는 RF 가 아니라 CU 에만 연결하도록 최적화해 크게 늘지 않았다 §VII-C p.9. 주파수가 같다는 것이 이후 IPC 비교의 전제다. backend 의 Issue stage 는 Execute 에 근접하므로, 더 큰 구성에서는 Issue 가 critical path 가 될 여지가 있다 해석.

Fig.13 — 5.2.cFig. 13: Absolute cycles of the baseline and both sCROOGe schemes for each application in the (32,4) configuration. (p.9) (32,4) 구성에서 22 개 application 의 실행 cycle 이다(파랑 baseline, 초록 frontend, 주황 backend, log 축). 대부분 application 에서 cycle 이 줄었고, 논문은 backend 27.3%, frontend 6.7% 를 적는다 §VII-C p.9. Intro 는 27.3% 를 "up to" 로 쓰지만 §I p.2, 6.7% 가 최대인지 평균인지는 원문에 명시 없음. backend 는 renaming 으로 WAR·WAW 를 없애고 operand 가 준비된 CU 를 바로 dispatch 해, frontend 보다 더 많은 명령어를 앞당길 수 있다. 논문은 backend 우위를 "더 복잡하고 강한 reordering 메커니즘" 으로 설명한다 §VII-C p.10.

Fig.14 — 5.3.cFig. 14: Speedup w.r.t. baseline for differently scaled frontend- and backend-based sCROOGe configurations. (p.10) x 축은 (warp, thread) 20 개 구성, 막대는 baseline 대비 IPC 증가율이다. 주황 계열은 backend 의 CU 2~14 개, 초록 계열은 frontend 의 IsB 2~12 entry 다. backend 가 모든 구성에서 frontend 보다 높고, backend 이득은 thread 가 늘수록 줄며, warp 수에는 뚜렷한 경향이 없다 §VII-C p.10. frontend 는 대부분 구성에서 이득이 작고 가장 작은 구성에서는 오히려 느려진다. 논문은 frontend 가 추가한 pipeline stage 의 비용이 reordering 이득보다 커지는 경우라고 설명한다 §VII-C p.10. warp 수에 경향이 없다는 점을 논문은 TLP 가 충분하든 부족하든 OoO 가 이득을 준다는 근거로 든다 §VII-C p.10.

Fig.16 — 5.4.cFig. 16: Stalls breakdown of the baseline (left), frontend OoO (middle) and backend OoO (right), w.r.t. the baseline cycles (16 warps, 32 threads per warp). (p.10) application 마다 막대 세 개(baseline · frontend · backend)이고, 높이는 baseline 전체 cycle 대비 stall cycle 비율이다. 색은 그 cycle 에 겹친 stall 종류다: sched(scheduler 가 보낼 warp 명령어 없음), exu(실행 유닛 구조 hazard), dpnd(RF 읽기 직렬화 + 의존성) §VII-C p.10. 총 stall 이 frontend −11.8%, backend −14.8% 로 줄고, 특히 scheduler stall 이 −51%, −61% 줄었다. backend 에서는 의존성만으로 생긴 stall 도 줄었다. 논문은 backend 가 새 stall 원인을 추가하지만 효율적 reordering 과 RF 접근 감소로 상쇄한다고 쓴다 §VII-C p.10.

Fig.19 — 5.5.cFig. 19: Area & power overheads across sCROOGe schemes for different SM configurations, synthesized at 400 MHz. (p.11) 위 두 칸은 면적, 아래 두 칸은 전력이고, x 축은 IsB(frontend) 또는 CU(backend) 수 4~14 다. 왼쪽은 16 warp × 4·8 thread, 오른쪽은 32 warp × 32 thread·64 warp × 32 thread 이며, 파란 선이 baseline 이다. frontend 는 면적 최대 7.5%, 전력 8.2% 로 구성에 상관없이 비슷하고, backend 는 최대 28.6%, 32.1% 이며 큰 (warp, thread) 구성에서 기울기가 가파르다 §VII-E p.11. 논문 설명에 따르면 frontend 추가분은 주로 register(순차 소자)로 늘어나고, backend 추가분은 warp·thread 에 따라 비선형으로 커지는 interconnect 를 다루는 조합 논리라서다 §VII-E p.11.

Table IV — 5.6.cTABLE IV: Iso-area comparison of sCROOGe with a baseline of increased warps (W) and the same threads per warp (T). (p.12) backend OoO(32 warp) 와, 면적이 비슷하거나 약간 더 큰 baseline(64 warp)을 같은 thread 수로 비교했다. 세 구성 모두 OoO 의 IPC 가 높아 16.30%·11.61%·15.30%, 평균 14.4% 다 §VII-E p.12. 면적 열의 "479,2" 같은 표기는 원문 그대로다. 논문은 이를 warp 를 늘려 얻는 TLP 이득은 포화에 가깝고, ILP 가 남은 개선 여지라는 가설의 근거로 든다 §VII-E p.12. Fig.12 에서 baseline IPC 가 warp 수에 둔감한 것과 같은 방향이다 해석.

Fig.23 — 5.7.cFig. 23: sCROOGe schemes right-sizing across {Warp,Thread} configurations regarding ADP, EDP FoM. Optimal CU and IsB counts are outlined and FoM improvement on the optimal values is annotated. (p.13) 왼쪽은 frontend(IsB 수), 오른쪽은 backend(CU 수)다. 행은 warp 수(4~64)마다 ADP·EDP 두 줄, 열은 thread 수(4~32)마다 IsB/CU 수를 늘린 칸이다. 색은 baseline 대비 정규화 값(초록 < 1 이 좋음, 빨강 > 1)이고, 노란 칸이 최적점과 그 개선율이다 §VII-F p.12. 16 warp 구성이 CU 를 가장 잘 공유해 개선이 가장 크다(EDP 최대 frontend 12.4%, backend 27.9%). warp 가 적으면 reordering window 가 덜 차고, 많으면 window 가 붐벼 구조를 키운 만큼 성능이 늘지 않는다. warp 가 가장 많은 구성은 작은 CU 수에서 EDP 를 최대 18.6% 개선한다. {64,32} 는 두 방식 모두, 4·8 warp 와 {64,16} 은 frontend 에서 비효율적이다 §VII-F p.12.

Fig.10 · Fig.11 · Fig.12 — workload 의 ILP 와 baseline 성능

Fig.12 — 5.10.cFig. 12: Baseline Vortex IPC per SM configuration. (p.9) baseline 의 (warp, thread) 별 IPC 분포(violin)다. IPC 는 warp 수에 둔감하고 thread 수에는 거의 선형으로 늘며, 대부분 workload 는 4 warp 에서 포화한다 §VII-C p.9.

Fig.15 · Fig.17 · Fig.18 — 여러 SM, ML workload, cache 크기

Fig.18 — 5.13.cFig. 18: Performance and load latency of the OoO schemes w.r.t. to L1 and L2 sizes (16 warps, 32 threads per warp). (p.11) 왼쪽은 IPC 이득, 오른쪽은 load latency 감소율의 분포이고, L1·L2 를 절반·두 배로 바꿨다. L1 을 키우면 두 방식 모두 이득이 조금(< 2%) 늘고 latency 경향은 뚜렷하지 않다. L2 를 키우면 backend 의 이득과 latency 감소가 각각 2.5%, 6% 줄어든다 §VII-D p.11. 논문은 L2 hit rate 가 오르면 memory stall 이 짧아져 OoO 가 숨길 stall 이 줄기 때문이라고 설명한다 §VII-D p.11.

Fig.20 · Fig.21 · Fig.22 — 주파수·전압과 component 별 비용

Fig.22 — 5.16.cFig. 22: Area and power breakdown of the proposed execution schemes per component. (p.12) 면적(왼쪽)과 전력(오른쪽)을 component 로 나눴다. baseline 대비 늘어난 부분은 Issue stage 뿐이다(면적 16.9% → frontend 17.5% → backend 24.7%) §VII-E p.12. 원문 전력 축 표기는 mW 다.

Fig.24 — PnR 과 2nm 로 synthesis 결과 다시 확인

6결론과 한계

논문의 결론은 sCROOGe 가 GPU 의 frontend·backend instruction reordering 을 처음으로 합성 가능한 RTL 로 구현해 면적·전력·주파수를 ASIC synthesis 로 검증하는 platform 을 만들었고, 가벼운 OoO 가 EDP 를 최대 27.9% 줄이며 warp 를 늘리는 방식보다 14% 넘게 앞선다는 것이다 §VIII p.13.
논문에 limitation 절은 없다. 아래는 요약자가 정리한 한계다 논문에 없음.

6.1

한계	근거
6.1.1평가 대상이 Vortex SM 이다. NVIDIA 급 구성(64 warp × 32 thread)에서는 OoO 이득이 작고(backend 4.18%, frontend 0.86%) 면적·전력 overhead 가 커서, 논문 스스로 이 구성에서의 유효성에 의문을 적는다	Table II p.3, §VII-E p.11
6.1.2RTL 정확도의 기준이 실측 실리콘이 아니다. Accel-Sim 은 V100 실측과 비교했지만, sCROOGe 의 cycle·전력은 Verilator·synthesis·PnR 결과이며 실제 칩 측정은 없다	§II p.2, §VII-G p.12
6.1.3workload 가 Vortex 의 OpenCL benchmark 22 개와 작은 ML kernel 4 개(llama-260k 등)라, 대형 GPU workload(Rodinia·Deepbench 전체, 큰 LLM)에서의 이득은 확인되지 않았다	§VII-A p.8, §VII-C p.10–11
6.1.4Table II 비교는 sCROOGe 의 RTL 판과 원 논문 simulator 수치의 비교라, baseline micro-architecture(Vortex vs NVIDIA 계열)의 차이도 함께 섞여 있을 수 있다	§II p.3 (iso-resource 구성 가정)
6.1.5memory 명령어 reordering(LSQ)은 Vortex workload 에서 상한 1.1% 미만이라 뺐다. memory 병렬성이 큰 workload 에서는 판단이 달라질 수 있다	§V-C p.7–8
6.1.6공정 라이브러리가 NDA 라 면적·전력 수치는 csv 로만 재현 가능하고, 같은 PDK 접근권이 있어야 독립 검증할 수 있다	Appendix H p.14

7관련 연구

Table I 은 기존 OoO GPU 7 개가 모두 simulator(PTXPlus·SASS·Multi2Sim)로 성능을, GPUWattch·AccelWattch·부분 합성으로 전력·면적을 평가했고, clock(timing)은 아무도 평가하지 않았다고 보인다 Table I p.2.
sCROOGe 는 frontend·backend 를 모두 RTL 로 구현하고 22nm·2nm 전체 합성으로 PPA 와 clock 을 함께 잰다 §III p.4.

연구	한 일	sCROOGe 와 차이
7.2.1LOOG	OC stage 에서 CU + register renaming 으로 backend reordering	simulator 평가. CU 를 writeback 까지 점유, LSQ 포함 (§I, §V-C)
7.2.2GhOST · SIMIL	Issue stage 에서 dependence checker 와 queue 로 frontend reordering, renaming 없음	simulator + 부분 합성. IBuffer·sync flag 등 sCROOGe 에서 없앤 부품 있음 (§III, §V-B)
7.2.3Warped-P	stall 중 독립 명령어를 pseudo-speculative 하게 issue	speculative path 에 한정, 진짜 OoO 아님 (§III p.4)
7.2.4HAWS	compiler hint 로 stall 중 issue 를 안내	compiler 의존 (§III p.4)
7.2.5Turbulence	거리 기반 operand 인코딩으로 ISA 를 바꿔 renaming 회피	ISA·toolchain 변경 필요 (§III p.4)
7.2.6MIAOW · Vortex · Skybox · SoftGPU · VeriGPU · Nyuzi	합성 가능한 open-source GPU RTL	모두 in-order. MIAOW 는 cache·memory controller 를 생략한 hybrid 모델 (§III p.4)

8세미나 발표 대본 (약 19 분)

Fig.1~24 와 Table I~IV 를 발표 순서대로 놓고, 그림마다 말할 내용을 2~4 문장으로 적었다. 세부 회로와 지엽적인 수치는 줄이고, 문제 → 설계 → 실험 환경 → 평가 흐름을 남겼다.
발화문은 요약자가 쓴 것이고 논문에 없음, 수치와 주장은 원문에서 확인한 것만 넣었다. caption 끝의 시간은 권장 분량이다.

펼치기: 그림별 발화 (Fig.1~24, Table I~IV)

도입 · 40 초

오늘 소개할 논문은 ISCA 2026 의 sCROOGe 입니다. GPU 에 CPU 처럼 out-of-order 실행을 넣자는 연구는 여럿 있었지만 모두 simulator 로만 평가됐습니다. 이 논문은 open-source RISC-V GPU 인 Vortex 에 두 가지 OoO 방식을 실제 RTL 로 만들고 22nm 로 합성해서, 성능·면적·전력·주파수를 다시 쟀습니다. 결론은 simulator 가 이득을 과대평가했지만, 잘 맞춘 구성에서는 warp 를 늘리는 것보다 OoO 가 낫다는 것입니다.

1 부 · 문제 (약 2 분 15 초)

x 축은 Accel-Sim 이 예측한 cycle, y 축은 실제 V100 에서 잰 cycle 이고 점 하나가 kernel 하나입니다. 점이 대각선에서 벗어난 만큼이 오차인데, 평균 오차가 11.55% 입니다. Deepbench 만 보면 30% 를 넘고, GRU inference 는 73% 까지 틀립니다. 기존 micro-architecture 에서도 이 정도이니, 새 구조를 넣으면 더 틀릴 수 있다는 것이 출발점입니다.

이 논문의 문제 제기를 가장 직접 보여 주는 표입니다. 왼쪽 세 열은 LOOG, GhOST, SIMIL 원 논문이 simulator 로 보고한 값이고, 오른쪽 두 열은 같은 64 warp, 32 thread 구성을 RTL 로 만들어 잰 값입니다. IPC 이득은 23%, 6.9%, 31% 에서 backend 4.18%, frontend 0.86% 로 줄고, 면적 overhead 는 backend 21.5% 로 커집니다. frontend 의 0.86% 는 저자들도 오차 범위 안이라고 말합니다.

기존 OoO GPU 일곱 개를 평가 방법으로 정리한 표입니다. 성능은 모두 simulator, 전력·면적은 모델이나 부분 합성이고, clock 열은 모두 X 입니다. sCROOGe 만 RTL 과 전체 합성으로 네 항목을 다 잽니다.

2 부 · 설계 (약 5 분 20 초)

Vortex pipeline 전체 그림이고, 색으로 네 부류를 나눕니다. 파랑은 원래 Vortex, 초록은 frontend 방식, 주황은 backend 방식, 보라는 둘이 공통으로 쓰는 UUID 생성기입니다. frontend 는 Issue stage 앞쪽의 Issue Buffer 에서, backend 는 operand 를 모으는 Collector Unit 에서 순서를 바꿉니다. 추가 부품이 모두 Issue stage 근처에 모여 있고 Execute 와 memory 는 그대로라는 점을 봐 두시면 됩니다.

OoO 로 실행해도 원래 순서를 알아야 하므로, 명령어마다 warp 별 순번 UUID 를 붙입니다. 순번을 짧게 두고 돌려 쓰기 위해 상위 2 bit 가 11 다음 00 으로 넘어가는 것을 "뒤" 로 봅니다. 이 회로는 바퀴가 다른 순번이 한 stage 에 섞이는 경계 상황을 비교기로 잡아 pipeline 을 멈춥니다.

frontend 방식의 핵심 회로입니다. Issue Buffer 에 있는 명령어의 source·destination register 를, 이미 내보낸 명령어 목록인 In-Flight buffer 와 Issue Buffer 의 다른 명령어와 비교합니다. RAW, WAW, WAR 세 hazard 를 비교기로 검사해 의존 bit 두 묶음을 만듭니다. renaming 이 없으니 세 가지를 모두 검사해야 합니다.

frontend 의 명령어 흐름을 번호 순서로 따라갑니다. ① decode 된 명령어가 Issue Buffer 에 들어가고, ② 다음 cycle 에 Dependence Checker 가 의존 bit 를 채웁니다. ③ Issue Arbiter 가 의존이 없는 명령어를 골라 내보내고, ④ In-Flight buffer 에 그 destination 을 적습니다. 이후 실행은 baseline 과 같고, ⑨ writeback 이 끝나면 기록을 지웁니다. 원래 설계는 독립 명령어가 없을 때 가장 오래된 명령어를 냈는데, 그것이 scoreboard 에서 막히는 일이 많아 독립 명령어만 내도록 바꿨고, 그 덕에 scoreboard 자체를 없애며 IPC 도 2% 올랐습니다.

backend 로 넘어가서, 먼저 RRS 가 왜 필요한지 보여 주는 그림입니다. x 축은 빈 Collector Unit 이 없어서 멈춘 cycle 의 비율이고, 선은 workload 와 구성의 누적 분포입니다. 보라선은 RRS 없이 CU 가 writeback 까지 붙잡히는 경우, 남색은 RRS 12 개를 둔 경우입니다. 80% 의 application 기준으로 이 stall 비율이 42% 이상에서 23% 이상으로 내려갑니다. CU 하나가 RRS entry 보다 4 배 넘게 크기 때문에, CU 를 늘리는 것보다 RRS 로 일찍 풀어 주는 편이 쌉니다.

backend 의 흐름입니다. ① 명령어는 순서대로 빈 CU 에 들어가며 RRS entry 를 하나 받고, ② RAT 를 보고 operand 를 register file 에서 읽을지 다른 명령어의 결과 broadcast 를 기다릴지 정합니다. 동시에 자기 RRS 번호를 RAT 에 적어 뒤 명령어가 자기를 기다리게 합니다. ③④ operand 가 다 모이면 ready 가 되고, ⑤ Dispatch Arbiter 가 ready 인 것 중 하나를 매 cycle 실행으로 보냅니다. 늦게 들어온 명령어라도 먼저 준비되면 먼저 나가는 것이 OoO 의 핵심입니다.

위는 Cycle X, 결과가 RRS 에 쌓이고 RAT 를 확인해 register file 에 쓰는 단계입니다. 아래는 Cycle X+1, 결과를 모든 CU 에 broadcast 하는 단계입니다. 원래는 RRS entry 하나하나가 모든 CU 에 선을 가져야 해서 배선이 RRS 수에 비례했는데, writeback 이 cycle 당 하나뿐이니 중간 register 하나를 거치게 해 배선을 RRS 수와 무관하게 줄였습니다. 이 추가 cycle 은 원래 있던 writeback 두 단계 안에 숨깁니다.

LOOG 는 memory 명령어도 재배치했는데, 이 그림은 그 상한을 구성별로 계산한 것입니다. 모든 구성에서 평균 1.1% 미만입니다. 실제로 넣어 보면 면적 8.7%, 전력 9.3% 가 들어서, sCROOGe 는 이 부품을 뺐습니다. RTL 로 비용을 재야 내릴 수 있는 결정의 예입니다.

3 부 · 실험 환경 (약 1 분 40 초)

실험 환경입니다. GPU 실물이 아니라 RTL 로 만든 Vortex SM 하나, processing block 하나에 L1 16 KB 구성을 평가하고, DRAM 은 Ramulator 로 붙였습니다. 성능은 Verilator 로 RTL 을 그대로 돌려 cycle 을 세고, 면적과 전력은 Synopsys Design Compiler 로 GlobalFoundries 22nm FDSOI, 0.9 V, 25°C 조건에 합성해 얻습니다. register file 과 cache 는 실제 SRAM macro 를 쓰고, 전력은 gate-level simulation 의 switching activity 로 PrimeTime 이 계산합니다. 일부 구성은 Cadence Innovus 로 배치·배선까지 하고, IMEC 2nm PDK 로도 확인합니다. workload 는 Vortex 의 OpenCL benchmark 22 개와 llama2-Gemm, AlexNet conv layer, SqueezeNet layer, llama-260k 네 개의 ML kernel 이고, 구성은 warp 4~64, thread 4~32 를 훑습니다. 비교 대상은 수정하지 않은 in-order Vortex 입니다.

workload 에 순서를 바꿀 여지가 얼마나 있는지를 본 그림입니다. 명령어 수를 가장 긴 의존 사슬로 나눈 평균 ILP 이고, 22 개 application 이 2.02 에서 2.92 사이입니다. 즉 평균적으로 동시에 실행 가능한 독립 명령어가 2~3 개 있습니다.

backend 가 실제로 몇 개를 추월하는지 본 그림이고, 선은 CU 수 6~14 개입니다. 대부분 한 개만 추월하고, 네 개 이상은 10% 미만입니다. CU 가 많을수록 오른쪽 꼬리가 길어져 조금 더 깊게 재배치합니다.

4 부 · 평가 (약 8 분)

먼저 주파수입니다. Issue stage 지연이 baseline 295 ps 에서 frontend 600, backend 901 ps 로 늘지만, 가장 긴 경로는 세 설계 모두 Execute 993 ps 입니다. 그래서 셋 다 1 GHz 로 돌고, 이후 성능은 IPC 로 바로 비교할 수 있습니다. 다만 backend 는 한계에 꽤 가까이 와 있습니다.

비교 기준인 baseline 의 IPC 를 구성별로 그린 violin 입니다. thread 를 늘리면 IPC 가 거의 선형으로 오르지만, warp 를 늘려도 거의 변하지 않고 대부분 4 warp 에서 포화합니다. warp 를 더 넣는 TLP 방식에 한계가 있다는 배경입니다.

32 warp, 4 thread 구성에서 application 별 실행 cycle 이고, 파랑 baseline, 초록 frontend, 주황 backend 입니다. 대부분 application 에서 cycle 이 줄고, 논문은 backend 27.3%, frontend 6.7% 를 적습니다. 27.3% 는 서론에서 "최대" 로 쓴 값입니다.

전체 설계 공간의 IPC 증가율입니다. x 축은 warp·thread 구성 20 개이고, 주황 계열 막대는 backend 의 CU 수, 초록 계열은 frontend 의 Issue Buffer 크기입니다. backend 가 모든 구성에서 frontend 보다 높고, thread 가 늘수록 이득이 줄어듭니다. frontend 는 대부분 이득이 작고, 가장 작은 구성에서는 추가한 pipeline stage 때문에 오히려 느려집니다.

SM 을 1, 2, 4 개로 늘리고 workload 도 같이 키운 결과입니다. 4 SM 에서 baseline 4.44 배에 대해 frontend 4.69, backend 4.74 배로, SM 이 늘어도 이득이 유지됩니다. 조금 줄어드는 것은 공유 memory interface 경합 때문이라고 설명합니다.

이득이 어디서 왔는지 보는 그림입니다. application 마다 막대 세 개가 baseline, frontend, backend 이고, 색은 그 cycle 에 겹친 stall 종류입니다. 노랑 sched 는 scheduler 가 낼 명령어가 없는 경우, 파랑 exu 는 실행 유닛 충돌, 빨강 계열 dpnd 는 의존성과 register file 읽기입니다. 총 stall 이 frontend 11.8%, backend 14.8% 줄었고, 특히 scheduler stall 이 51%, 61% 줄었습니다. 막혀 있던 warp 대신 뒤의 독립 명령어를 낼 수 있게 된 효과입니다.

ML kernel 네 개의 결과입니다. 위 초록이 frontend, 아래 주황이 backend 이고, 칸마다 행은 warp, 열은 thread 입니다. llama2-Gemm 은 두 방식 모두 이득이 크고, CNN-Layer 는 renaming 이 있는 backend 에서만 크게 오릅니다. 서론 기준 ML 에서 최대 53% 입니다.

cache 크기 민감도입니다. 왼쪽이 IPC 이득, 오른쪽이 load latency 감소입니다. L2 를 키우면 memory stall 이 짧아져 OoO 가 숨길 것이 줄고, backend 이득이 2.5% 줄어듭니다.

이제 비용입니다. 위가 면적, 아래가 전력이고, x 축은 Issue Buffer 또는 CU 개수, 파란 선이 baseline 입니다. 초록 frontend 는 어느 구성이든 면적 최대 7.5%, 전력 8.2% 로 완만합니다. 주황 backend 는 면적 28.6%, 전력 32.1% 까지 오르고, 64 warp, 32 thread 같은 큰 구성에서 급격히 가팔라집니다. frontend 는 register 위주로, backend 는 warp·thread 에 따라 커지는 연결 논리로 늘어나기 때문입니다.

합성 주파수를 200 MHz 에서 1 GHz 로 바꾸며 면적과 전력을 찍은 그림입니다. 주파수 5 배에 면적은 6% 정도 늘지만 전력은 4 배가 됩니다. timing 을 맞추려고 더 센 cell 을 쓰기 때문입니다.

왼쪽은 backend 의 전압·주파수 조합별 전력이고, 빨강은 동작할 수 없는 영역, 굵은 칸은 각 전압의 최적점입니다. 오른쪽은 그 최적점에서 application 별 와트당 IPC 입니다. 전력은 전압 제곱으로, 성능은 대략 전압에 비례해 늘어 전압이 오를수록 효율이 떨어집니다.

면적과 전력을 부품별로 나눈 그림입니다. 세 설계에서 달라지는 것은 연보라 Issue stage 하나뿐이고, backend 에서 면적 비중이 16.9% 에서 24.7% 로 커집니다.

그러면 같은 면적을 OoO 에 쓰는 것과 warp 를 늘리는 데 쓰는 것 중 무엇이 나을까요. 왼쪽은 32 warp 의 backend OoO, 오른쪽은 면적이 비슷하거나 약간 큰 64 warp in-order 입니다. 세 구성 모두 OoO 가 IPC 가 높아 평균 14.4% 앞섭니다. warp 를 늘리는 이득은 포화에 가깝고 ILP 가 남은 여지라는 것이 저자들의 해석입니다.

성능과 비용을 합쳐 구성별 최적 크기를 찾는 그림입니다. 왼쪽이 frontend, 오른쪽이 backend 이고, 행은 warp 수마다 면적×시간인 ADP 와 에너지×시간인 EDP, 열은 thread 수마다 Issue Buffer 나 CU 개수입니다. 초록일수록 baseline 보다 좋고, 노란 칸이 최적점입니다. 16 warp 구성이 가장 좋아 EDP 가 frontend 12.4%, backend 27.9% 개선되고, 64 warp, 32 thread 는 두 방식 모두 비효율적입니다.

마지막으로 합성 결과를 배치·배선까지 해서 확인했습니다. 왼쪽이 22nm, 오른쪽이 2nm 이고, 빗금이 합성, 채운 막대가 배치·배선 후 전력입니다. 배선 때문에 절대 전력은 늘지만 모든 설계에 고르게 늘어, baseline 대비 overhead 차이는 frontend 0.8%, backend 1.7% 이내입니다. 그래서 전체 설계 공간을 합성 결과로 탐색한 것이 타당하다고 주장합니다.

마무리 · 40 초

정리하겠습니다. sCROOGe 는 GPU 의 두 가지 OoO 방식을 처음으로 실제 회로로 만들어, simulator 가 성능 이득을 크게, 면적·전력 비용을 작게 보았다는 것을 보였습니다. 그럼에도 16 warp 정도의 구성에서는 EDP 가 최대 27.9% 좋아지고, 같은 면적이면 warp 를 늘리는 것보다 14.4% 빠릅니다. 한계로는 평가가 Vortex SM 과 작은 workload 에 한정되고, NVIDIA 급 64 warp, 32 thread 구성에서는 이득이 작고 비용이 크다는 점, 그리고 실리콘 실측이 아니라 합성·배선 결과라는 점을 들 수 있습니다.