일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 컨벌루션 연산
- pygraphviz 설치 오류
- 남산업힐
- Pyverilog 실행
- pytest-pythonpath 설치 오류
- 이진수 곱셈 알고리즘
- Data HAzard
- Pyverilog 설치
- CDC
- makefile
- 대구 반도체 설계기업 특화
- CLOCK GATING
- CUDA
- DNN 가속기
- AMBA
- systolic array
- 데이터 해저드
- linux c++ 컴파일
- Pyverilog 튜토리얼
- pyverilog 설치 오류
- gpgpu-sim
- gcc 컴파일
- Design DNN Accelerator
- 딥러닝 가속기
- Makefile compile
- linux makefile 작성
- 클럭 게이팅
- DNN Accelerator
- linux c 컴파일
- Pyvrilog tutorial
- Today
- Total
오늘은 맑음
multi-thread processor에서의 scoreboard 본문
저번 포스팅에서는 일반적인 in-order processor에서의 scoreboard에 대해서 알아보았습니다.
이번에는 highly parallel architecture processor에서의 scoreboard에 대해 알아보겠습니다.
과연 두 개의 차이점이 무엇일까요?
highly parallel architecture은 즉, thread가 매우 많은 multi-thread processor라고 할 수 있습니다.
multi-thread processor의 경우 예를 들어보겠습니다.
1. 1개의 warp당 128개의 register를 갖고있습니다.
2. 1개의 core당 64개의 warp을 갖고있습니다.
그렇다면 총 register의 개수는 총 8912개가 존재하며, in-order processor에서 사용하였던 일반적인 scoreboard를 사용하게 되면 8912bit이 필요합니다. 엄청나게 많은 register를 필요로 하네요...
하지만 이게 다가 아닙니다. 만약 scoreboard의 register에 write를 할 명령어로 인해 의존성(dependency)이 생기면 수 많은 thread들이 scoreboard에 접근해 의존성 여부를 체크해야 하는데 하나의 thread가 체크하는동안 나머지 thread들은 대기를 하게 됩니다... 이는 엄청난 성능 하락으로 이어지겟죠??
만약 모든 thread들을 접근해서 체크하게 하고 싶다면 socreboard에 엄청 많은 read port를 두어야 하는데 이에 대한 비용 역시 만만치 않습니다.
또한 지금 명령어가 발행(issue)된 thread들에게 모두 의존성이 존재한다면??
모두 정지(stall)하게 될 것이며 더이상 명령어는 발행되지 않는 문제가 발생해 후속 명령어가 의존성이 존재하지 않더라도 처리하지 못하는 상황이 발생하게 됩니다.
위와 같은 이유로 인해 일반적인 scoreboard를 multi-thread processor에 적용하기에는 어려움이 많습니다.
이를 해결하기 위한 방법으로는 다음 논문에 설명이 되어 있습니다.
Coon, Brett W., et al. "Tracking register usage during multithreaded processing using a scoreboard having separate memory regions and storing sequential register size indicators." U.S. Patent No. 7,434,032. 7 Oct. 2008.
간단히 설명 드리자면, scoreboard memory에는 instruction에 명시된 operand를 식별할 수 있는 register identifier라는 항목이 존재하며 의존성 체크는 다음과 같이 이루어집니다.
1. A라는 instruction이 fetch되어 instruction buffer에 추가됩니다.
2. A가 실행 될 thread에서 A의 register identifier와 scoreboard의 register identifier를 비교하여 결과를 multi-bit의 vector로 생성합니다.
3. scoreboard에서 생성된 multi-bit은 instruction buffer로 전송되어 A와 함께 저장됩니다.
4. 만약 A에서 사용할 register가 write 대기중이라면, multi-bit에 표시가 되어 이 명령어를 실행시키지 못하게 할 것입니다. 만약 이전 명령어의 실행이 종료되면 의존성은 사라지게 되므로 A를 실행시킵니다. 또는 의존성이 없다면 실행을 시킵니다.
5. instruction buffer에 instruction과 함께 저장된 multi-bit은 같은 thread에서 실행이 종료되면 update하게 됩니다.
만약 instruction buffer의 모든 항목들이 사용중이어 더이상 명령어를 fetch하지 못할 때는 stall되거나, instruction buffer 내의 대기중인 명령어들을 포기한 뒤 나중에 다시 fetch함으로써 의존성이 없는 명령어들을 발행할 수 있게 합니다.
선행 명령어가 종료됨으로써 의존성이 사라지는 순간 할당되었던 항목은 clear되며 instruction buffer에 있는 의존성 비트를 clear시킴으로써 다음 명령어를 실행시킬 수 있게 합니다.
'Processor' 카테고리의 다른 글
MSHRs(Miss Status Holding Registers) (0) | 2019.02.27 |
---|---|
Data Prefetch (1) | 2019.02.21 |
Register Scoreboarding/스코어보드 (2) | 2019.02.19 |
Data Hazard/RAW, WAR, WAW (1) | 2019.02.19 |
SIMT 교착상태(deadlock), 기아(starvation) (0) | 2019.02.18 |