총 SM 수 + 하드웨어 구조에 따라, 각기 다른 Block/Grid 전략

GPU 스케줄러는 원하는 block 을 모두 동시에 실해하지 않는다. 

제한된 수의 block 만 SM 에 올려서 처리, 나머지는 대기 큐에 머문다.

즉, SM 개수가 곧 병렬성의  실제 상한

 

기본 구조

총 SM 수 = 80
grid = 1000 blocks
block당 thread = 256

실행 흐름:
 80개 block만 동시에 실행
 다른 920개 block은 큐에서 기다림

총 SM 개수, occupancy, register/shared mem 사용량에 따라 한 번에 올릴 수 있는 block 개수를 최적화하는 게 핵심이 된ㄷ.ㅏ

 

Real Strategy - "Block > SM is a must"

block 개수는 반드시 SM 개수보다 훨씬 많아야 한다. 그래야 SM 을 100% 점유 가능

 

block = SM : 1 block/SM -> Warp 끝나면 idel, 낮은 활용도

block = SM x 10 : SM 마다 대기 block whswo , 높은 활용도

block = SM x 50 : 충분히 대기 block 많음, 안정적

 

즉, -> grid size must be >> SM_count

왜? Warp 끝날 때마다 바로 다음 block 을 얹어야 idle 없음

 

 

그럼 block 당 thread 수는? (thread/block)

block 당 thread 수는 SM 의 warp scheduler * register 수와 연관됨

 

block 당 thread

( 64 ~ 128 ) : latency hiding 약하지만 너무 좁음 

256 : warp 8 개 = SM scheduler 에 적합하지만, general recommend 

( 512 ~ 1024 ) : register pressure ↑, occupancy ↓, 커널 한정 최적화

따라서 block_size = 256 은 일반적인 sweet spot