소스 코드에서 하드웨어 실행까지 이어지는 추적 가능한 분석 모델의 구축

 

이 표현은 단순히 소스 코드와 SASS를 나란히 보여준다는 뜻이 아니다.
핵심은 고수준 코드가 어떤 변환을 거쳐 실제 GPU 명령이 되고, 그 명령이 실행 과정에서 어떤 현상을 만들었는지를 연속적으로 추적할 수 있는 분석 구조를 만든다는 데 있다.

전체 흐름은 다음과 같다.

CUDA 소스 코드
    ↓ 컴파일
PTX 중간 표현
    ↓ 아키텍처별 코드 생성
SASS 기계어
    ↓ GPU 실행
실행 cycle, stall, pipeline, memory, register metric

기존 분석은 이 단계들을 따로 보는 경우가 많았다.

소스 코드는 소스 코드대로 확인
SASS는 디스어셈블 결과로 따로 확인
성능은 실행 시간이나 NCU metric으로 따로 확인

이 방식에서는 성능 문제가 발견되어도 그것이 어느 코드 구조에서 시작되었는지 다시 수작업으로 역추적해야 한다.

반면 추적 가능한 분석 모델에서는 각 계층을 하나의 연결된 구조로 본다.

소스 줄
→ 생성된 SASS 명령
→ 레지스터 및 메모리 의존 관계
→ 실행 중 발생한 stall
→ 커널 전체 성능 변화

즉, 단순한 관찰이 아니라 원인과 결과의 경로를 구성하는 것이다.

---

1. 여기서 말하는 ‘모델’의 의미

여기서 모델은 머신러닝 모델이 아니다.

다음 정보들을 관계로 표현한 분석용 표현 체계에 가깝다.

소스 코드 위치
컴파일 결과
기계어 명령
레지스터 데이터 흐름
메모리 접근
실행 metric

예를 들어 하나의 소스 줄을 다음처럼 표현할 수 있다.

Source Node
- file: probe_kernels.cu
- line: 104
- code: x = fmaf(x, multiplier, addend)

이 소스 노드에 대응되는 SASS 노드를 연결한다.

SASS Node 1
- address: 0x3d0
- opcode: FFMA
- read: R9, R0
- write: R9

그리고 실행 정보를 다시 연결한다.

Runtime Node
- executed: 2048
- stall samples: dependency-related
- pipeline: FP32

결국 하나의 분석 단위는 다음처럼 구성된다.

소스 코드
    ↓ generated-as
SASS 명령
    ↓ executed-with
실행 metric

이 관계 자체가 분석 모델이다.

---

2. ‘추적 가능하다’는 의미

추적 가능하다는 것은 양방향으로 이동할 수 있다는 뜻이다.

소스에서 실행으로

이 CUDA 코드가
→ 어떤 SASS로 변환되었고
→ 어떤 레지스터를 사용했으며
→ 실행 중 어떤 stall을 만들었는가

실행에서 소스로

이 SASS 주소에서 stall이 많이 발생했다
→ 어느 명령인가
→ 어떤 소스 줄에서 유래했는가
→ 어떤 코드 구조가 원인인가

예를 들어 NCU에서 특정 FFMA 구간의 stall이 높게 나타났다고 하자.

0x3d0  FFMA R9, R9, R0, ...
0x3e0  FFMA R9, R9, R0, ...
0x3f0  FFMA R9, R9, R0, ...

이를 역추적하면:

동일한 R9를 반복 사용
→ 긴 RAW dependency chain
→ 이전 FFMA 결과를 기다려야 함
→ latency hiding이 제한됨
→ dependency 관련 stall 증가 가능

여기서 다시 소스 코드로 올라가면:

x = fmaf(x, a, b);
x = fmaf(x, a, c);
x = fmaf(x, a, d);

같은 단일 accumulator 구조가 원인임을 찾을 수 있다.

이것이 단순한 metric 관찰과 다른 점이다.

---

3. 분석 모델을 구성하는 핵심 연결 정보

이 모델이 성립하려면 각 계층 사이를 연결하는 공통 정보가 필요하다.

소스 코드 ↔ SASS

컴파일러가 남긴 line information을 사용한다.

SASS address
→ source file
→ source line

예:

0x3d0
→ probe_kernels.cu
→ line 104

SASS 내부 관계

operand를 분석해 레지스터와 메모리 의존성을 구성한다.

instruction A writes R9
instruction B reads R9

따라서:

A → B

라는 데이터 흐름 관계를 만든다.

SASS ↔ 실행 정보

명령 주소를 기준으로 runtime metric을 연결한다.

0x3d0
→ instructions executed
→ warp stall samples
→ pipeline category
→ register state

결국 세 계층이 하나의 주소 체계로 연결된다.

Source line
    ↕
SASS address
    ↕
Runtime metric

---

4. 단순 대응표가 아니라 인과 분석 구조

단순 대응은 다음 수준이다.

CUDA 104번째 줄
→ FFMA 8개 생성

추적 가능한 분석 모델은 그보다 한 단계 더 나아간다.

CUDA 104번째 줄
→ 동일 accumulator를 사용하는 FFMA 8개 생성
→ 최장 의존 체인 길이 8
→ ILP가 낮음
→ dependency stall 증가
→ kernel cycle 증가

즉, 다음 흐름을 구성하는 것이다.

코드 구조
→ 컴파일러 변환
→ 기계어 구조
→ 하드웨어 실행 특성
→ 성능 결과

이 흐름이 구축되면 단순한 “느리다”를 넘어 다음처럼 설명할 수 있다.

커널이 느린 이유는 FFMA 개수가 많아서가 아니라, 동일한 accumulator를 연속적으로 갱신하면서 긴 데이터 의존 체인이 생성되었기 때문이다. 이 구조는 독립적으로 발행할 수 있는 명령 수를 제한하고, 결과적으로 실행 지연을 숨기기 어렵게 만든다.

이런 설명이 가능해지는 것이 분석 모델의 핵심 가치다.

---

5. 분석 단위는 소스 줄보다 더 넓을 수 있다

실제로는 한 소스 줄과 한 SASS 명령이 정확히 대응하지 않는다.

따라서 분석 모델의 단위는 보통 다음처럼 계층적으로 구성하는 것이 좋다.

Kernel
└── Source Region
    ├── Source Line
    ├── SASS Basic Block
    │   ├── Instruction
    │   ├── Register Dependency
    │   └── Memory Access
    └── Runtime Metrics

Kernel 단위

kernel duration
register usage
occupancy
memory throughput
instruction count

Source region 단위

루프, 조건문, reduction, epilogue 같은 의미 있는 코드 구간이다.

loop body
address calculation
main computation
output store

SASS basic block 단위

분기 없이 연속적으로 실행되는 명령 구간이다.

instruction sequence
dependency chain
pipeline composition

Instruction 단위

opcode
operand
register read/write
execution count
stall sample

이처럼 여러 해상도를 제공해야 한 줄 단위 분석의 한계를 피할 수 있다.

---

6. 이 모델을 통해 가능한 분석

컴파일러 변환 분석

FMA fusion 여부
loop unrolling 여부
dead code elimination
branch와 predication 선택
address calculation 증가

데이터 흐름 분석

longest dependency chain
independent instruction chain 수
중심 accumulator
RAW dependency

레지스터 분석

live register 변화
peak register pressure
lifetime이 긴 값
spill 발생 위치

메모리 분석

어느 소스 접근이 LDG/STG로 변환됐는가
주소 계산 비용
load 이후 소비까지의 거리
memory dependency

실행 병목 분석

dependency-limited
memory-limited
pipeline-limited
register-pressure-limited
control-flow-limited

수정 효과 분석

코드를 수정한 뒤 동일한 추적 구조를 다시 만들면 이전 결과와 비교할 수 있다.

before
CUDA → SASS A → runtime A

after
CUDA → SASS B → runtime B

이를 통해:

소스 변경
→ SASS 구조 변화
→ metric 변화
→ 최종 성능 변화

를 확인할 수 있다.

---

7. 중요한 것은 ‘성능 수치’보다 ‘변화 경로’

예를 들어 실행 시간이 다음처럼 바뀌었다고 하자.

기존: 10.2 μs
수정: 8.4 μs

단순 benchmark는 17.6% 빨라졌다는 사실만 알려준다.

추적 가능한 분석 모델은 왜 빨라졌는지 설명한다.

accumulator 1개
→ accumulator 4개

longest dependency chain
128 → 32

live registers
10 → 17

dependency stall
감소

occupancy
소폭 감소

kernel duration
17.6% 감소

이 결과를 통해 다음과 같은 더 깊은 결론을 얻을 수 있다.

독립 accumulator를 늘리면서 레지스터 사용량은 증가했지만, dependency chain 단축으로 얻은 ILP 증가가 occupancy 감소 비용보다 컸다.

이것이 2차 분석이다.

---

8. 나아가 ‘예측 가능한 분석’으로 발전할 수 있다

분석 모델이 반복적으로 쌓이면 단순 설명을 넘어 예측에도 활용할 수 있다.

예를 들어 여러 실험에서 다음 관계가 관찰됐다고 하자.

independent accumulator 증가
→ dependency depth 감소
→ live register 증가
→ 특정 지점 이후 occupancy 감소

이 데이터가 누적되면 새로운 커널에 대해 다음을 예상할 수 있다.

accumulator를 2개에서 4개로 늘리면 개선 가능
8개 이상에서는 register pressure가 병목이 될 가능성

즉:

관찰
→ 관계 모델링
→ 새로운 코드에 대한 예측

으로 발전한다.

장기적으로는 다음 형태도 가능하다.

CUDA 코드 입력
→ 예상 SASS 구조 추정
→ 잠재 dependency chain 식별
→ register pressure 위험 분석
→ 최적화 후보 제안

---

9. GPU probing 프로젝트에서의 의미

GPU probing 관점에서 이 분석 모델의 목적은 NCU 화면을 다시 만드는 것이 아니다.

NCU는 이미 다음을 잘 제공한다.

source
SASS
runtime metric

프로젝트가 추가해야 할 부분은 그 사이의 관계를 자동으로 해석하는 것이다.

NCU가 제공하는 것:
관찰 데이터

분석 모델이 제공해야 하는 것:
관찰 데이터 사이의 인과관계

예를 들면:

관찰:
FFMA 구간에서 stall sample이 높다.

분석:
동일한 R9를 사용하는 16단계 의존 체인이 존재한다.

해석:
FFMA throughput 부족보다는 dependent latency가 제한 요인이다.

제안:
accumulator를 분리해 독립 FFMA chain을 생성한다.

검증:
SASS chain depth와 runtime cycle 변화를 비교한다.

이렇게 되면 프로젝트는 단순한 프로파일링 도구가 아니라:

코드 변화가 컴파일 결과와 하드웨어 실행에 미치는 영향을 추적하고 설명하는 분석 시스템

이 된다.

---

10. 문서에 사용할 수 있는 정리 문장

소스 코드에서 하드웨어 실행까지 이어지는 추적 가능한 분석 모델이란, CUDA 소스 코드와 컴파일된 SASS 명령어, 그리고 실제 실행 중 수집된 하드웨어 성능 정보를 하나의 연속된 관계 구조로 연결하는 분석 체계이다. 이를 통해 특정 코드가 어떤 기계어로 변환되었는지뿐 아니라, 해당 명령 구조가 레지스터 의존성, 메모리 접근, pipeline 활용, warp stall과 같은 실행 현상에 어떤 영향을 주었는지를 추적할 수 있다. 분석의 목적은 단순히 성능 수치를 제시하는 것이 아니라, 코드 구조에서 시작해 컴파일 결과와 실행 병목으로 이어지는 원인 경로를 복원하는 데 있다.

더 압축하면 다음과 같다.

고수준 코드, 기계어, 실행 metric을 연결해 성능 현상의 원인을 코드 수준까지 역추적할 수 있는 분석 구조를 구축하는 것이다.

결국 핵심 구조는 다음 한 줄로 정리된다.

코드를 본다
→ 생성된 명령을 본다
→ 실제 실행을 본다
→ 세 정보 사이의 원인 관계를 설명한다