[컴퓨터구조] 4 프로세서 (4.6 파이프라이닝 개요)

※"컴퓨터 구조 및 설계 6판 MIPS EDITION" 책을 간단하게 정리한 내용의 글입니다.※

4.6 파이프라이닝 개요

파이프라이닝(pipelining)은 여러 명령어가 중첩되어 실행되는 구현 기술이다.

파이프라이닝의 역설적인 점은 파이프라이닝을 한다고 해서 어떤 작업 하나를 완료하는 데 걸리는 시간은 줄일 수 없지만, 여러 작업에 대해서는 전체 걸리는 시간이 줄어든다는 점이다.

파이프라이닝에서 속도 향상은 파이프라인 단계 수와 같다. 단계 수가 4단계인 경우에는 속도가 4배 향상될 것이다.
하지만 실제로는 파이프라이닝의 시작과 끝 부분에서는 모든 단계가 가득 차있지 않기 때문에 4배의 속도 향상은 될 수 없다. 대신 작업 수가 많을 수록 4배에 근접하게 된다.

단일 사이클 구현에서 클럭 사이클은 가장 느린 명령어(lw)를 기준으로 정해진다.

파이프라인 구현에서는 모든 단계가 한 클럭 사이클에 처리된다. 이때 파이프라인 실행 클럭 사이클은 가장 느린 동작을 수용할 만큼 충분히 길어야 한다. 위의 예시에서 클럭 사이클 시간은 최악의 경우인 200ps가 된다.

명령어의 수가 많은 경우에 파이프라이닝을 통한 명령어들의 실행 시간은 거의 파이프라이닝되지 않은 명령어들의 실행 시간 / 파이프라인 단계 수에 근접하다.
원래 파이프라인 단계 수가 5단계이면 원래 800ps가 걸리던 것이 160ps가 걸려야할 것 같지만, 파이프라이닝은 어느정도의 오버헤드를 포함한다. 위의 그림에서 명령어 3개를 파이프라이닝으로 실행하는 경우 2400ps / 3 = 800ps가 아닌 1400ps가 걸린다. 이는 파이프라인의 각 단계의 클럭 사이클이 200ps로 고정됐기 때문이고, 파이프라인을 꽉 채우지 못하는 단계가 있기 때문이다.

< 파이프라이닝을 위한 명령어 집합 설계 >

MIPS 명령어는 파이프라이닝을 고려하여 설계되었고, 다음과 같은 특징을 가지고 있다.

• 1. 모든 MIPS 명령어는 같은 길이를 갖는다.
     이를 통해 명령어를 가져오고 해독하는 단계를 나누는 것을 쉽게 해준다.
• 2. MIPS는 명령어 형식이 적고, 일관된 구조를 가지고 있다.
     MIPS 명령어에서 opcode와 sr 필드는 같은 위치에 있다. 이 명령어 구조의 일관성 덕분에 CPU는 명령어 종류를 해석하면서 필요한 레지스터 값을 바로 읽을 수 있다.
• 3. MIPS에서는 메모리 피연산자가 적재와 저장 명령어에서만 나타난다.
• 4. MIPS 피연산자는 메모리에 정렬(align)되어 있어야 하고, 따라서 한 데이터 전송 명령어 때문에 메모리 접근을 두 번 하는 경우는 없다.
     프로세서와 메모리 사이의 데이터 전송은 항상 파이프라인 단계 하나에서 처리된다.

< 파이프라인 해저드 >

다음 명령어가 다음 클럭 사이클에 실행될 수 없는 상황을 해저드(hazard)라고한다. 해저드에는 구조적 해저드, 데이터 해저드, 제어 해저드가 있다.

< 구조적 해저드(structural hazard) >

같은 클럭 사이클에 실행하기를 원하는 명령어의 조합을 하드웨어가 지원할 수 없는 경우에 발생하는 해저드를 구조적 해저드(structural hazard)라고 한다.

< MIPS 명령어 파이프라인의 도시 >

IF: 명령어 인출 단계
ID: 명령어 해독/레지스터 파일 읽기 단계
EX: 실행 단계(ALU)
MEM: 메모리 접근 단계
WB: 쓰기 단계
위의 그림은 add 명령어의 예시로, 오른쪽 반이 어두운 것은 오른쪽 반이 어두운 것은 그 단계에서 읽기 작업이 일어나는 것이고, 왼쪽 반이 어두운 것은 쓰기 작업이 일어나는 것이다. add 명령어의 경우 메모리 접근을 하지 않기 때문에 MEM이 흰색인 것이다.

< 데이터 해저드(data hazard) >

데이터 해저드는 파이프라인 데이터 해저드라고도 한다. 명령어를 실행하는데 필요한 데이터가 아직 준비되지 않아서 계획된 명령어가 적절한 클럭 사이클에 실행될 수 없는 경우를 말한다.
어떤 명령어가 아직 파이프라인에 있는 앞선 명령어에 종속성을 가질 때 데이터 해저드가 일어난다.

위의 코드에서 sub 명령에서 add의 결과를 이용하고 있다. 하지만 MIPS 명령어 단계상 add의 결과가 5번째 단계의 WB가 일어난 후에 sub에서 이것이 사용될 수 있다. 이 경우 데이터 해저드가 발생한 것이다.

• 전방 전달(forwarding) 또는 우회 전달(bypassing)
  데이터가 레지스터에 쓰여지기 전에 별도의 하드웨어를 통해 값을 일찍 받아오는 것을 전방전달 또는 우회전달이라고 한다.

하지만 전방전달(forwarding)을 하더라도 지연이 필요한 경우가 있다. 위의 그림에서 처럼 lw 명령의 경우 MEM 단계에서 데이터를 가져오게 되는 경우이다. 전방전달을 통해 MEM에서 명령어를 가져오기 전에 sub에서 이를 전달 받을 수는 없기 때문에 전방전달을 하더라도 한 단계의 지연이 필요하다. 이를 적재-사용 데이터 해저드(load-use data hazard)라고 한다. 이는 데이터가 필요한 시점까지 데이터가 도착하지 않아서 생기는 특별한 형태의 데이터 해저드이다.

위의 그림은 파이프라인 지연(pipeline stall) 또는 거품(bubble)이라는 중요한 파이프라이닝 개념을 보여주고 있다.

• 파이프라인 지연을 피하기 위한 코드의 재정렬
  

  

  
  위의 경우 두 번의 add에서 바로 위의 lw에서 가져오는 값을 사용하기 때문에 2번의 파이프라인 지연이 발생한다.
  

  

  
  순서를 이렇게 바꿀 경우 명령어의 종속성이 해결되고 파이프라인 지연이 사라진다. 즉, 해저드가 모두 없어진다.

< 제어 해저드(control hazard) >

제어 해저드는 분기 해저드(branch hazard)라고도 한다. 인출한 명령어가 필요한 명령어가 아니기 때문에 적절한 명령어가 적절한 클럭 사이클에 실행될 수 없는 사건을 말한다.
원래 파이프라인에서 명령어 인출 단계에서 다음에 실행할 명령어를 인출한다. 하지만 조건부 분기 명령어로 인해 다음 사이클에 인출할 명령어를 아직 알 수 없다면 어떻게 해야 할까?

• 첫 번째 해결 방법: 지연
  해결 방법의 첫 번째는 다음 명령어를 알게 될 때까지 기다리는(지연시키는) 것이다.
  이 방식은 분기 명령어가 있는 경우에 항상 지연이 일어나고, 분기를 해결하는 데 더 많은 단계가 필요한 경우에 지연이 커지고 훨씬 큰 속도 저하를 가져오기 때문에 리스크가 있다.
• 두 번째 해결 방법: 예측
  두 번째 방법은 예측하는 것이다. 예측이 맞을 경우는 파이프라인의 성능을 떨어뜨리지 않는다. 하지만 예측이 틀렸으면 연산하던 것을 버리고 새로운 명령어를 인출해야 한다.
• 세 번째 해결 방법: 지연 결정(delayed decision)
  조건부 분기 명령어의 결과가 나오기 까지 관련 없는 명령어를 실행하는 방법이다.

파이프라이닝은 각 명령어의 지연시간(execution time 또는 latency)이 아니라 처리율을 향상시킨다.