파이프라이닝을 "단계를 겹친다" 수준에서 멈추는지, hazard 세 종류를 원인·완화 기법까지 분리해서 설명하는지를 가른다. 분기 예측 실패나 stall이 실제 코드 성능에 어떻게 번지는지 연결 짓는지도 본다.
명령어 파이프라이닝은 fetch·decode·execute·memory·writeback 같은 단계를 겹쳐 한 사이클에 한 명령씩 끝나는 것처럼 보이게 만드는 CPU 기법이다. 처리량은 단계 수에 비례해 늘어나는 것 같지만, 명령어 간 의존성이 있으면 데이터 hazard, 분기 결과가 늦게 확정되면 제어 hazard, 같은 자원을 동시에 요구하면 구조적 hazard가 터져 stall이나 flush로 빈 사이클이 생긴다. forwarding, interlock, branch prediction, 자원 분리로 hazard 비용을 깎는다. 결국 파이프라인 성능은 단계 수가 아니라 hazard를 얼마나 줄이느냐로 갈린다.
정렬된 입력과 비정렬 입력에서 같은 코드가 다르게 동작하는 걸 본 적이 있다면 분기 예측 실패와 연결할 수 있다
perf·VTune 같은 도구로 IPC나 branch-miss를 떠본 경험이 있다면 stall 종류를 가르는 사례로 풀 수 있다
분기를 테이블 룩업이나 비트 연산으로 바꿔 성능을 회복한 경험이 있다면 제어 hazard 회피 패턴으로 일반화할 수 있다
JIT나 컴파일러가 만든 어셈블리를 들여다본 경험이 있다면 forwarding이 깔린 흐름을 단계 그림으로 설명할 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.