CUDA Kernel Analysis System - Idea Exploration Draft

1. 출발점 - 커널을 이해하는 도구

CUDA 커널을 최적화하는 과정은 보통 다음과 같은 순서를 따른다. 

1. 코드를 읽고 구조를 추측한다.
2. Nsight Compute 를 실행한다.
3. 지표 확인
4. 병목 추정
5. 코드 수정
6. 다시 실행

지금까지 이 과정을 머릿속에서만, 비정형적으로 진행했음

• 분석 과정이 기록되지 않고
• 반복 실험의 구조가 남지 않으며
• 재현이 어려운 문제

CUDA 커널을 읽고 실행, 분석하는 과정 자체의 구조화를 통해 

Kernel Understanding Pipeline 을 생성

 

2. Kernel Development Philosophy

이 시스템의 목표는

완벽한 커널을 먼저 만드는 것이 아닌

커널의 실행 / 검증 / 분석 기록을 체계적으로 축적하는 것

커널을 단순한 코드가 아닌 실험 대상으로 다룬다.

 

각 커널 실행은 다음을 남긴다.

Input condition
Correctness validation
Performance metrics
Profiler snapshot

이러한 로그 축적을 통해

• 커널의 진화 과정
• 성능 변화
• 병목 패턴을 체계적으로 이해할 수 있다.

 

3. Kernel Analysis Pipeline ( Concept )

이 시스템의 개념적 구조

CUDA Kernel Source
        │
        ▼
[Static Kernel Analyzer]
        │
        ▼
[Execution + Validation]
        │
        ▼
[Dynamic Profiling]
        │
        ▼
[Metric Interpreter]
        │
        ▼
[Optimization Insight]

지표 수집이 아닌 지표 해석

왜 이러한 결과가 나왔는지 설명하는 시스템을 만드는 것

 

4. Static Kernel Analyzer ( 실행 이전 분석 )

NCU 기반 분석은 실행 이후 분석

하지만 CUDA 커널만으로도 정보 획득 가능

float a = A[row * K + k];
float b = B[k * N + col];

이 패턴만으로도 다음의 추론 가능

• row-major access
• stride pattern
• coalescing 가능성

 

Thread Mapping 분석

int row = blockIdx.y * blockDim.y + threadIdx.y;
int col = blockIdx.x * blockDim.x + threadIdx.x;

• thread - data mapping
• warp data coverage
• spatial locality

 

Sharaed Memory 사용

__shared__ float tileA[32][32];

• data reuse
• tiling 구조
• shared memory footpring

 

Static Analysis 에서 추출 가능한 정보

FLOPs estimate	연산량
Global memory access	DRAM traffic 추정
Shared memory usage	tiling 구조
Register usage	occupancy 제한
Memory stride	coalescing 가능성
Thread mapping	warp 데이터 분포

코드만 보고 커널의 구조적 성격을 추정

 

 5. Dynamic Profiling Layer

이 단계에서는 기존 도구 활용 ( NCU )

Compute Utilization : 연산 유닛 사용률 

Memory Utilization : 메모리 병목 여부

Occupancy : warp 병렬성

 

6. Static vs Dynamic 비교 

이 시스템의 목적은 차이를 설명하는 것 

 

7. Kernel Pattern Recognition ( 확장 아이디어 )

Static 분석이 발전하면 커널 패턴을 인식할 수도 있다.

패턴이 인식되면 다음의 제안 가능

Kernel Pattern: GEMM-like

Expected optimization:
- shared memory tiling
- double buffering
- cp.async

Kernel Knowledge Base 로 발전 가능

 

8. Optimization Suggestion Engine

궁극적으로 이 커널은 어떻게 빨라질 수 있는가에 대한 질문에 답

Case 1

DRAM throughput high
Compute utilization low

 

→ Memory Bound

Possible actions

• tiling
• shared memory reuse
• kernel fusion

---

Case 2

Compute utilization low
OI high

DRAM throughput high
Compute utilization low

→ latency / dependency

Possible actions

• loop unrolling
• instruction scheduling

---

Case 3

 

Occupancy low

Possible actions

• register pressure 감소
• shared memory usage 감소

 

9. Kernel Execution Record System

이 시스템의 중요 구성 요소는

Kernel Run Log 이다.

각 커널 실행은 하나의 실험 기록을 남긴다

기록 항목 예:

Execution Metadata

kernel_id
git_commit
arch (sm_86)
blockDim
gridDim
tile_size

 

Input Condition

shape
dtype
stride
alignment
seed

 

Correctness Validation

reference = PyTorch

max_abs_error
mean_abs_error
max_rel_error
worst_index

 

Performance

latency_us
achieved_GFLOPs
achieved_GBps

 

Profiler Snapshot

dram_throughput
sm_utilization
occupancy
register_per_threa

이러한 기록들은 다음을 가능하게 한다.

• 커널 성능 변화 추적
• 최적화 효과 비교
• 재현 가능한 실험

 

10. Visualization Layer

Kernel Insight Dashboard 형태로 발전 가능

Roofline Visualization

FLOP/s
vs
Bandwidth

커널 위치 표시

Stall Breakdown

memory dependency
barrier
scoreboard

 

Memory Hierarchy View

HBM
L2
L1
shared
register

이러한 시각화는

aicf-visual-lab 과 연결된다.

 

11. AICF 와의 연결

Kernel Analysis System 이 있으면

각 후보를 다음 기준으로 평가할 수 있다.

latency
throughput
occupancy
OI

즉

Op
 ├ candidate kernel A
 ├ candidate kernel B
 └ candidate kernel C

각 커널의 정량적 비교 가능

이는 결국

AICF 의 Kernel Selection 시스템으로 확장 가능

 

GPU 커널 최적화를 기록 가능한 공학 과정으로 만드는 것이 목표