aicf 의 메커니즘과 ge_v2 와의 비교

1) aicf 전체 메커니즘 

C++ 정적 라이브러리를 중심으로

• IR / Lowering / Runtime (CUDA Graph 캡처/리플레이)
• Backend (CUDA ops) 를 한 덩어리로 묶고, 예제에서 링크해서 실행하는 구조

Python 확장 중심이 아닌 C++ 코어 라이브러리 중심

aicf 호출 흐름

• include / aicf / ... 공개 API 호출
• (backend) src / backends / cuda / ops / * / launcher.cu
• (device) kernels.cuh 에 있는 __global__ / __device__ templete

 

2)  왜 aicf 는 api.hpp / launcher.cu / kernels.cuh 로 쪼갰나

(1) include / ... / api.hpp 는 ABI / 사용자 계약 (Contract) 라서

• 외부에서 include 되는 공개 헤더
• 최소한의 타입 / 함수 시그니처만 두는 게 유지보수에 유리
• 커널 구현 세부가 헤더에 섞이면 컴파일 폭발 + 의존성 폭발

api.hpp 는 링킹 대상이 되는 라이브러리의 표면만 남기는 게 정답

 

(2) launcher.cu 는 호스트 코드 + 런치 정책 + 디스패치라서 .cu 가정석

• grid / block 계산, shareed mem bytes 계산
• 템플릿 인스턴스 선택
• stream, workspace, alignment 체크

host code, C++ 쪽과 섞이기도 하고, nvcc 로 컴파일되어야 하므로 launcher.cu 가 맞음

 

(3) kernels.cuh 가 나온 이유 : 커널은 템플릿 / 인라인 중심이 되기 때문

향후 Tensor Core / WMMA, tiling 변형, epilogue 퓨전 같은 역할을 하려면

• template<int TILE_M, ...> 처럼 템플릿화
• __device__ 유틸/프래그먼트 연산 인라인화
• 여러 .cu 들을 같은 커널을 include 해서 인스턴스화 

이때 .cu 로 두면

• translaton unit 에서 재사용하기 까다로움
• 템플릿 인스턴스 관리가 지저분
• 중복 컴파일 / 링크 이슈 

커널은 헤더, 런처만 .cu 가 흔한 패턴

 

3) CMake 관점에서 aicf 가 깔끔해진 이유

aicf 는 빌드 산출물

• aicf.lib
• 예제 exe 들

이라서 ops 마다 pyd 를 따로 만드는 복잡한 타겟들이 없음

ge_v2 는 _ops_* 모듈을 많이 만들고 그걸 Python 패키지가 로드하는 구조, CMake 타겟이 폭발하기 쉬움