6. 파이프라인 (2/4) 해저드

파이프라인은 이론상 M단계 파이프라이닝을 도입하면

M배의 성능 향상을 생각하겠지만, 실제로는 이런 저런 이유로 성능이 크게 떨어진다.

 

 

해저드엔 3가지가 있다.

1. 구조적 해저드

2. 데이터 해저드

3. 명령어 해저드

 

해저드를 없애기 위해서는, 파이프라인에 명령어 투입을 멈춰야 한다.

이를 파이프라인 중지 또는 파이프라인 버블(NOP Sled) 이라고 한다.

하지만, 파이프라인 버블이 많아지면, 성능 향상이 크게 떨어지기 때문에,

S/W구현에선, 컴파일러의 도움으로 명령어 순서를 변경하거나,

H/W구현에선 파이프라인을 다시 설계하거나 자원을 추가한다.

 

 

구조적 해저드

실행 중인 2개 이상의 명령어가 동일한 하드웨어 자원을 동시에 요구하는 문제

 

EX) LOAD명령과 다른 여러 명령어들을 실행하는 과정에서,

LOAD가 메모리에서 데이터를 읽기를 수행해야 하는데,

다른 명령어가 메모리에서 명령어를 인출(fetch)하려는 과정이 충돌

 

해결 방법

메모리 접근 충돌은 명령어/데이터 메모리(캐쉬)를 분리

PC값 증가는 ADDR 추가로 해결.

HW 추가 분할, 예약표, 입출력 포트 다중화

자원충돌 가능성이 높은 단계는 예약표 기능 적용

 

데이터 해저드

연산할 데이터가 준비되지 않아 파이프라인을 멈춰야 하는 상황.

주로, 선행 명령어와 후행 명령어가 같은 데이터를 사용하는 과정에서 발생

 

Ex)

add r1, r2, r3

sub r3, r1, r2

 

가 있다고 하면, 파이프라인으로 정리해보면 이런식이다.

 

add r1, r2, r3

      sub r3, r1, r2

 

순차적인 방식이라면, r1 = r2 - r3을 실행한 뒤, r1 값을 sub의 r1에 넣어야 하지만,

add연산이 끝나기 전에 sub명령어는 r1 읽어 해저드가 발생한다.

 

데이터 관계에는 다음 3가지가 있다.

 

1. 쓰기 후 읽기(RAW)

2. 읽기 후 쓰기(WAR)

3. 쓰기 후 쓰기(WAW)

 

RAW 해저드는 문제가 없지만, 주로 읽기 후 쓰기(WAR)에서 문제가 발생한다.

이는, 선행 명령어가 데이터를 읽기 전, 후행 명령어가 먼저 데이터를 갱신하는 경우이다.

WAW 해저드는 선행명령어가 데이터를 갱신하기 전에 후행 명령어가 먼저 갱신하는 경우다.

 

해결 방법

 

포워딩을 통한 데이터 해저드 해결

-> ALU 출력으로 직접 데이터를 받아, ALU로 재전송.

컴파일러에서 의존성 분석 후, 재배치

 

 

명령어 해저드

실행할 명령어가 결정되지 않았거나, 준비되지 않아서 생기는 문제.

주로 분기 명령어서 일어나고,

분기가 결정되는 시점엔, 파이프 라인엔 이미 후속 명령어들이 채워져

실패에 대한 패널티가 크다.

즉, 분기를 탈 경우 파이프라인을 재구성 해야 된다.

 

명령어 해저드가 영향

5단계의 파이프 라인을 사용하는 아키텍처에서

명령어 해저드가 없는 경우 CPI 가 1

명령어의 17%가 분기 명령어이고, 분기 패널티가 3사이클일 때

 

명령어 해저드가 있을 때 성능 감소율 : 1 + 0.17*3 = 1.51 성능은 0.66밖에 나오지 않는다.

 

만약 3개 명령어를 동시 실행할 수 있는 슈퍼 스칼라의 경우

해저드가 없을 때 CPI는 1/3 = 0.33

해저드가 있을 땐 CPI는 0.33 + 0.17 * 3 = 0.84 => 0.33/0.84 = 0.38로 심각한 패널티

 

이를 해결하기 위한 방법으론, 명령어 인출 단계에 분기 명령어를 식별하는 HW를 추가하면 되지만,

이는 추가 부하로 클럭 속도가 느려질 수 있게 됨

아니면 NOP SLED를 태우면 된다.