HPCA 2020 · CASINO Core Microarchitecture
들어가며
CES는 의존성 chain을 별도의 P-IQ에 배치하여 복잡한 선택 하드웨어를 줄였다. 그러나 독립적인 Ready 명령어가 많으면 P-IQ가 부족해질 수 있었다. CASINO는 출발점이 다르다. “처음부터 실행 가능한 명령어는 간단한 앞단에서 처리하면 어떨까?”라는 질문이다.
이 글은 CASINO의 동작을 첨부한 Ballerino 논문 Section II-B2, Figure 3(b)(c), Section II-C의 설명을 기준으로 정리한다.
1. Readiness에 초점을 맞춘 스케줄링
다음 코드를 생각하자.
I1: a = load(A) // cache miss
I2: b = a + 1 // not ready
I3: c = x + y // ready
I4: d = z + 3 // ready단일 In-Order Queue에서는 준비되지 않은 I2가 앞에 있으면 I3, I4도 issue를 기다릴 수 있다. CASINO는 짧은 Speculative In-Order IQ(S-IQ)들을 연속으로 배치한다. S-IQ에서는 선두 일부 명령어를 검사해 준비된 명령어를 issue하고, 미발행 명령어들을 뒤쪽 stage로 넘겨 다음 기회를 제공한다.
CASINO는 S-IQ를 직렬로 연결하고 뒤쪽에 In-Order IQ를 둔다. Ready 명령어는 앞쪽에서 issue 기회를 얻는다.
2. S-IQ가 하는 일과 하지 않는 일
S-IQ의 Speculative는 Runahead의 ‘미래 명령어를 Commit하지 않고 미리 실행’하는 모드와 동일하지 않다. CASINO는 일반 CPU 실행 파이프라인 안에서 Ready 명령어를 발행하는 제한적인 동적 스케줄링을 수행한다.
S-IQ는 load 결과를 예측해서 주소를 임의로 만들어내는 구조가 아니다. 입력값이 준비된 명령어를 선택하는 구조이다. 따라서 독립적 Ready 연산은 앞서 나갈 수 있지만 실제 데이터 의존성을 깨지 않는다.
3. CASINO의 이점: Ready-at-dispatch 명령어 처리
많은 명령어는 Dispatch 시점에 입력값이 준비돼 있거나 짧은 시간 안에 준비된다. 이들을 모두 복잡한 OoO IQ에 보낼 필요가 없다는 것이 CASINO의 통찰이다. Ready 후보를 S-IQ에서 먼저 처리하면 뒤쪽 IQ에 저장할 명령어를 줄일 수 있다.
Ballerino 논문의 Figure 3(c)에서 CASINO는 load-independent 명령어의 Ready-to-Issue 지연이 작은 경향을 보여준다. 이는 Readiness 기반 filtering의 장점을 설명하지만, 긴 메모리 접근을 동반한 전체 workload 성능까지 보장하는 것은 아니다.
4. 마지막 In-Order IQ
CASINO의 앞쪽 S-IQ를 통과했지만 끝내 Ready가 되지 못한 명령어들은 마지막 In-Order IQ로 도달할 수 있다. 다음 상태를 보자.
Last IQ
I2: Waiting for load A <- head
I5: Ready
I6: ReadyI5와 I6가 완전히 준비됐더라도 Last IQ가 In-Order issue를 강제한다면 I2를 추월할 수 없다. 이것은 Head-of-Line Blocking이다.
마지막 In-Order IQ의 선두 명령어가 긴 Cache Miss를 기다리면 뒤쪽 Ready 명령어들도 막힐 수 있다.
특히 서로 다른 load-dependent chain이 마지막 IQ에 섞이면 하나의 오래된 miss가 많은 명령어의 issue를 가로막을 수 있다.
5. 왜 S-IQ를 계속 늘리기만 하면 안 될까?
S-IQ를 여러 단계 배치하면 일부 명령어는 더 많은 Ready 확인 기회를 얻을 수 있다. 하지만 뒤쪽으로 밀려나는 load-dependent 명령어들이 마지막 IQ에 남는 문제가 없어지지는 않는다. 또한 stage 간 명령어 전달과 다수 read port의 하드웨어 비용도 고려해야 한다.
Ballerino 논문 Figure 17(a)의 sensitivity analysis는 CASINO가 소규모 issue-width에서는 효과적이지만 wide-issue 구성으로 갈수록 CES나 Ballerino보다 확장성이 떨어지는 경향을 보인다고 설명한다.
6. CES와의 비교
CASINO는 Ready filtering에 유리하고 CES는 별도의 dependence chain 관리에 유리하다.
CES는 다른 P-IQ의 head가 Ready라면 독립적으로 issue할 수 있지만, 새 chain을 받아줄 P-IQ가 부족하면 Steering Stall이 발생한다. CASINO는 Ready 명령어를 앞단에서 빠르게 issue하지만, 마지막 단일 In-Order IQ는 긴 load를 기다릴 때 취약하다.
따라서 두 설계는 서로의 한계를 완화할 가능성이 있다. Ballerino는 CES의 병렬 P-IQ 앞에 CASINO에서 착안한 S-IQ를 배치한다.
참고 문헌과 근거
I. Jeong, S. Park, C. Lee, W. W. Ro, “CASINO Core Microarchitecture: Generating Out-of-Order Schedules Using Cascaded In-Order Scheduling Windows,” HPCA 2020.
I. Jeong et al., “Reconstructing Out-of-Order Issue Queue,” MICRO 2022, Section II-B2, Section II-C, Figure 3, Section VI-E. 본 글은 후자 논문에 제시된 CASINO 설명과 재평가 결과를 주된 근거로 사용한다.