컴퓨터 구조 (7), Pipelining

Pipelining

 

 

 

- 매 사이클마다 단계를 진행할 수 있도록 하는 파이프라인 버퍼가 위와같이 존재한다.

- MIPS는 최대 5단계가 존재해 이를 효율적으로 사용하고자 했다.

 

Pipeline Hazards

- 파이프라인을 사용했을 때 빠르게 처리하다보니 결과값이 달라질 수 있는 이슈가 존재한다.

- 크게 Structural hazards, Data hazards, controal hazards가 있다.

- Structural hazards는 메모리를 나눠서 해결할 수 있다.

- Data hazards는 stall을 통해 이를 해결할 수 있지만 성능이 많이 떨어진다. 대표적인 Data hazards로는 Read After Write 문제가 발생할 수 있다. 데이터 포워딩을 해 write에 대해 데이터가 쓰여지기 전에 받아와서 사용할 수 있다. 다만 하드웨어가 복잡해진다.

- control hazard는 브랜치가 발생했을 때 어디로 이동해야하는지를 계산해야하기에 매우 어렵다.

 

데이터 포워딩

 

- Stall을 안할 수 있으면 최대한 줄이는 것이 중요하다.

 

- 컴파일에서는 의미가 바뀌지 않는 선에서 명령어의 순서를 바꿔서 스케줄링을 진행한다. 데이터 포워딩 외에도 스케줄링을 하는 것이 Data hazards를 제거할 수 있다.

 

 

 

 

실제 스케줄링을 했을 때의 로드로 인한 stalling을 줄일 수 있다.

 

 

ALU가 끝나면 브랜치가 일어나는지 일어나지 않는지 확인할 수 있다. 이에 따라 두개의 단계를 지나야지 control hazard가 발생한다. (어디로 가야하는지 모름) -> 이를 고려하면 3사이클을 쉬어야한다.

 

 

 

 

 

1. 간단하지만 성능이 떨어진다.

2. 2번 대안은 1번보다  훨씬 많은 개선이 발생한다.

 

- 반복문은 backward 방향으로 가기에 테이큰되는 경우가 존재한다. 이를 예측해 stall이 아니라 prediction을 진행한다.

- taken과 not taken은 컴파일 과정에서 결정한다.

- 컴파일 단계에서 backwards는 taken, 그 외는 not taken해서 하는 경우 예측을 높일 수 있다.

 

- 연산의 종류에 따라 걸리는 시간이 다르게 된다.

- 나누기는 훨씬 오랜 시간이 걸린다.

 

- 명령어 길이가 다른 경우에도 문제가 발생할 수 있다.

 

 

- 파이프라인 hazard가 파이프라인을 만들어서 빠르게 동작하게끔하는 것을 어렵게 만든다.

- load delay slots: 로드해서 순서를 바꾸는 것

- stall, branch delay slot, branch prediction을 해서 control 하자드를 완화한다.

 

 

- 브랜치 테이큰/낫 테이큰을 프레딕션하다가 잘못되었음을 판단하는 경우에는 N x W만큼 명령어 슬롯이 낭비된다.

- 실제 15 ~ 20%는 브랜치가 등장한다.

- 잘못된 것을 판단하는 경우 branch resolution latency라고 한다.

- W는 몇개의 인스트럭션이 함께 들어가는지에 대한 얘기이다.

 

- 브랜치가 taken인지 not taken인지는 가장 마지막에 판단할 수 있다. 이에 따라 잘못 판단했을 때 브랜치 예측 정확도에 따라 실제로 실행되는 정확도가 얼마나 되는지 확인해야한다.

- 100% 다 맞다면 한 클락당 5개씩 패치되기에 100사이클이 발생한다. 그러나 1%의 잘못된 예측이 있다면 다시 패치해야하는게 100개의 명령어를 다시 패치해야하기에 120사이클이 발생한다. 5%만 틀려도 2배의 사이클이 더 발생한다. 이를 고려해봤을 때 브랜치는 자주 등장하기도 하고 성능관리 측면에서 굉장히 중요하다.