Chapter 9. 파이프라이닝

# 본 내용은 한국항공대학교 길현영 교수님의 '컴퓨터 구조' 강의 및 컴퓨터 아키텍처(우종정, 한빛 아카데미)를 바탕으로 작성한 글입니다.

 

 

앞서 배웠던 다중 사이클이 파이프라이닝을 위한 것이라고 말해도 될 정도로 연관 있다.

파이프라이닝은 프로세서 성능에 영향을 미치는 요인중 CPI와 관련 있다.

즉, 파이프라이닝을 통해 평균 CPI를 감소시켜 성능을 좋게 만들어준다.

 

자세한 내용은 아래에서 공부해보자.

 

1. 파이프라이닝 개요

앞에서도 몇 번 예를 들었지만 세탁물로 예를 들어보자.

 

세탁, 탈수, 건조, 옷장 이 4가지 과정을 거쳐 세탁을 한다고 하자.

단순히 순차적으로 세탁->탈수->건조->옷장->세탁->탈수->건조->옷장.. 과정을 거치면서 세탁을 할 수 있다.

이는  정직하게 각각의 시간을 합한 시간이 전체 세탁 시간이 된다.

 

이것보다 더 빠르고 효율적으로 하는 방법이 없을까? 없을 리가

아래의 그림을 보자.

 

순차적 세탁 vs 병행적 세탁

 

4번의 세탁 과정이 나타나 있다.

위는 순차적으로 세탁한 과정이다. 딱 봐도 길어 보인다.

아래는 병행적으로 세탁한 과정이다. 딱 봐도 짧아 보인다.

 

차이는 건조와 세탁은 다른 과정이기 때문에 동시에 하고 있고, 다른 과정들도 마찬가지로 동시에 여러 작업을 수행하고 있다.

 

이를 지금까지 배운 다중 사이클과 살짝 연결시켜서 생각해보면

다중 사이클은 한 사이클 내에 hw를 여러 번 사용할 수 있다.

음.. 살짝 감이 올 것이다.

 

 

파이프라이닝이란 명령어의 데이터 경로를 세분화하고, 각기 다른 세부 단계를 동시에 수행하게 함으로써, 여러 명령어들을 중첩 수행 가능하게 만들어 성능을 향상하는 것을 의미한다.

 

아까의 세탁물을 그저 컴퓨터적으로 표현한 사진일 뿐이다.

보면 명령어 인출, 레지스터, ALU, 데이터 접근, 레지스터 이 과정은 적재 과정이네요..?

 

그럼 파이프라이닝을 무조건 써야 되는 거 아닌가?

맞는 말이긴 한데 나중에 공부할 거지만 파이프라이닝을 수행하기 어렵게 하는 부분들이 존재한다.

이를 해저드라고 하는데 지금은 간단하게 무조건 파이프라이닝이 가능한 건 아니구나 정도로 이해하고 넘어가자.

 

 

2. 순차 처리와 병행 처리

 

x에 대하여 y = f(x)를 계산하려 할 때 이를 위한 프로세서를 구현하는 방식으로 순차 처리, 병렬 처리, 병행 처리 세 가지가 있다.

 

순차 처리는 데이터가 입력되었을 때 클록마다 한 개의 데이터가 처리 가능하다.

즉 클록 시간이 T라면 n개의 데이터를 처리하는 데에는 nT의 시간이 걸린다.

 

병렬 처리와 병행 처리는 충분한 데이터가 주어진다면 데이터를 처리하는데 걸리는 시간이 nT/2로 준다고 한다.

 

그럼 병렬 처리와 병행 처리는 무슨 차이점이 있을까?

 

 

병렬 처리는 프로세서가 여러 개 필요하다.

즉 여러 개의 프로세서를 동시에 돌리기 때문에 DEMUX 같은 HW가 추가적으로 필요하다.

 

병행 처리는 하나의 프로세서를 2개로 분할해서 사용한다.

래치를 추가해야 하긴 하지만 병렬 처리에 비해 추가 비용이 거의 들지 않는다.

(래치는 Flip Flop과 비슷한 느낌의 기억소자, 임시 저장소라 생각하면 된다.)

 

이러한 병행 처리 기법이 바로 파이프라인 방식이다.

 

 

파이프라이닝의 성능

 

파이프라이닝이 성능을 향상시켜준다는 것까진 공부했다.

그럼 얼마나 향상될까?

 

아래와 같은 조건이 주어졌다고 생각해보자.

 

• 클록 주기 T
• m단계로 균등하게 분할된 파이프라이닝
• 래치에 대한 지연 시간 L
• 처리할 데이터의 수 n

이러한 조건의 파이프라이닝에 데이터가 들어왔다고 생각해보자.

 

첫 번째 데이터의 지연시간은 T + m*L이다.

순차 처리라면 T의 시간에 첫 번째 데이터가 처리되었겠지만, 병행처리에는 래치가 존재하기 때문에 래치에 대한 지연시간을 고려해주어야 한다.

즉 각 단계마다 래치에 대한 지연시간이 추가되므로 지연시간은 T + m*L 임을 알 수 있다. 

 

나머지 데이터들의 지연시간은 어떻게 될까?

나머지 n-1개의 데이터들의 지연시간은 T/m + L 일 것이다.

먼저 m단계로 균등하게 분할되었다고 가정했기 때문에 첫 사이클에 T/m+L 을 제외하고는 병행처리가 가능하다는 이야기이다.

 

아래 그림을 보자. 

 

 

이 그림은 3단계로 나눠진 파이프라이닝이라 할 수 있다.

이때 빨간색과 빨간색, 즉 각 단계 사이에 작은 파란색 사각형이 래치의 지연시간이다.

즉 요거 하나가 T/m + L이다.

 

그림을 보면 하나의 데이터가 끝나고 다음 데이터가 끝나는 시간의 차이는 위의 사진 하나 차이이다.

이유는 m단계로 균등하게 분할되었기 때문이다.

 

 

이제 나머지 n-1 단계에서의 지연시간이 T/m + L임을 알았으므로 전체 지연시간을 구해보면

 

파이프라이닝 구조에서 n개의 데이터 처리를 위한 시간은 (T + m*L) + (T/m + L)이다.

 

순차 처리에서의 n개의 데이터를 처리하려면 n*T 시간이 걸렸으므로 

순차 처리에 비한 파이프라인 방식의 속도 향상 s는 아래와 같다.

 

만약 데이터가 충분하다(무한하다) 면 s는 아래와 같이 계산할 수 있다.

 

이를 통해 파이프라이닝의 성능을 극대화하려면 어떻게 해야 하는지 유추할 수 있다.

 

• 래치 지연 시간이 파이프 지연 시간에 비해 무시할 정도로 작다면 (L이 0과 가까워짐)
• 처리할 데이터가 충분 (n -> 무한대)
• 파이프라인의 각 단계를 균등하게 분할 (균등하게 분할되어야 추가적인 지연시간 발생 X)
• 하나의 파이프에서 이웃한 파이프로 데이터를 이동할 때 동기화 필요: clock 사용
• Clock skew 문제: 물리적 전기신호의 특성으로 발생하는 clock의 시간 편차가 생김 (래치, 배선의 지연시간 등에 의해 클록의 도착 시간에 차이가 생길 수 있음. ex. 꼬마전구에서 배터리와 멀리 연결했을 때와 가까이 연결했을 때의 밝기 차이 등) 
• 명령어나 데이터 의존성 없음 (명령어가 순차적으로 처리되진 않는다. ex. j addr 처럼 점프하기 때문)

 

3. 해저드

 

이상적인 경우 m단계 파이프라이닝 기법을 도입하면 성능이 m배 향상될 것이다.

하지만 실제로는 그렇지 못하다.

여러 가지 원인이 있는데 이렇게 파이프라인 성능 향상을 어렵게 하는 원인들을 해저드라고 한다.

 

해저드의 종류에는 세 가지가 있다.

 

• 구조적 해저드
• 데이터 해저드
• 명령어 해저드

하나씩 공부해보자.

 

 

구조적 해저드

 

구조적 해저드란 파이프라인에서 실행 중인 2개 이상의 명령어가 동일한 하드웨어 자원을 동시에 요구하기 때문에 파이프라인을 멈춰야 하는 상황을 구조적 해저드라고 한다.

 

이해를 돕자면 세탁과정과 탈수과정을 파이프라이닝을 통해 동시에 수행하는데 같은 세탁기가 필요하기 때문에 해저드가 발생할 수 있다.

 

이러한 구조적 해저드를 해결하려면 명령어/데이터 메모리(캐시)를 분리하면 된다.

 

 

데이터 해저드

 

연산할 데이터가 준비되지 않아 파이프라인을 멈춰야 하는 모든 상황이나 조건을 데이터 해저드라고 한다.

 

주로 선행 명령어와 후행 명령어가 사용하는 데이터 간 종속성 문제로 발생하는데 이는 쉽게 말해

선행 명령어와 후행 명령어가 쓰는 레지스터가 같을 때 주로 발생한다.

 

선행 명령어의 시행을 통해 레지스터의 값이 바뀌는데 아직 값이 바뀌기도 전에 후행 명령어에서 해당 레지스터를 쓰면 엉뚱한 결과가 나올 것이다.

 

두 명령어가 공통으로 사용하는 데이터 관계는 다음과 같다.

 

• RAR (Read After Read) 
• RAW (Read After Write) 
• WAR (Write After Read) 
• WAW (Write After Write)

RAR관계는 프로세서의 상태를 변화시키지 않기 때문에 문제가 되지 않는다.

 

나머지 3개의 관계는 각각 해저드를 발생시킨다.

 

RAW 해저드는 파이프라인에서 선행 명령어가 데이터를 쓰기 전에 후행 명령어가 먼저 데이터를 읽는 경우에 발생하며, 다른 말로 순의존성이라고 한다.

 

(Read After Write에서 앞에 오는 Read를 후행 명령어라고 생각하면 편하다. 맞는진 모르겠지만..?)

 

WAR 해저드는 파이프라인에서 선행 명령어가 데이터를 읽기 전에 후행 명령어가 데이터를 갱신하는 경우에 발생하며 다른 말로 반의존성이라고 한다.

 

WAW 해저드는 파이프라인에서 선행 명령어가 데이터를 갱신하기 전에 후행 명령어가 먼저 갱신하는 경우에 발생하며, 다른 말로 출력 의존성이라고 한다.

 

WAR 해저드와 WAW 해저드는 주로 CISC 아키텍처에서 발생하므로 RAW 해저드만 살펴보자.

 

RAW 해저드는 계산 후 읽기와 적재 후 읽기로 구분된다.

(즉 후행 명령어가 언제 읽는지에 따라서 구분, 어떤 형식의 명령어인지에 따라 계산 및 적재로 구분될 수 있음)

 

 

계산 후 읽기 

 

위 그림과 같은 명령어 2개를 실행한다고 가정해보자.

 

I1 :  r1  <-  r2 + r3

I2 :  r4  <-  r1 + r5

 

I1은 r1을 레지스터 쓰기 단계(W)에서 덧셈한 결과로 갱신하고, 그 값을 I2은 레지스터 읽기 단계(D)에서 덧셈의 피연산자로 사용한다.

 

이때 파이프라이닝을 사용한다면 r1을 갱신시키지 전에 후행 명령어에서 r1을 사용하게 되면 결과가 달라진다.

 

 

적재 후 읽기

 

I1 = r1 <- M[r2 + 10]

I2 = r3 <- r1 + r4

 

r1값에 M[r2 + 10]을 적재해야 하는데 아직 접근하지 못한 상태에서 후행 명령어가 실행되면 결과가 달라진다.

 

 

 

명령어 해저드 

 

명령어 해저드 : 실행할 명령어가 결정/준비되지 않아서 멈춰야 하는 상황이나 조건

 

명령어 해저드는 주로 분기 명령으로 발생한다.

 

PC 갱신

 

예를 들면 분기 명령어의 조건을 만족하면 +1, 만족하지 못하며 -1 한다고 생각해보자.

 

나는 이제 분기 명령어의 조건을 비교하고 있는데, 파이프라이닝을 도입했기 때문에 PC, 즉 다음 실행할 명령어를 담는 레지스터에는 +1을 하는 명령어를 담아놓았다.

 

조건을 비교해보니 조건을 만족하지 않네? 그러면 +1이 아니라 -1을 해야 되므로 앞에 수행했던 과정들을 원래대로 복원시켜놔야 한다.

 

이 과정이 복잡하기 때문에 분기 명령어를 만났을 때에는 파이프라인을 일시적으로 중단하고 기다려야 된다고 한다.

 

명령어 해저드의 영향

 

먼저 시스템을 아래와 같이 가정해보자.

 

• 5-단계 파이프라인을 사용하는 picoMIPS 아키텍처
• 명령어 해저드가 없는 경우 CPI=1
• 명령어의 17%가 분기 명령어이며, 분기 페널티는 3사이클

만약 명령어 해저드가 발생한다면 평균 CPI는 다음과 같다.

1 + 0.17*3 = 1.51 (이유는 17%만큼의 분기 명령어에서 패널티 3사이클만큼 발생하기 때문)

따라서 성능은 0.66(1/1.51)만큼 감소한다.

 

만약 3개의 명령어를 동시에 수행할 수 있는 슈퍼스칼라 파이프라이닝 기법이라면

(해저드가 없을 때) 0.33 (=1/3)

(해저드가 있을 때) 0.84 (=0.33+0.17*3) 

즉 0.38 (=0.33/0.84) 만큼 성능이 감소한다.

이를 통해 파이프라인 기법을 이용하여 CPI를 낮추었을 때, 해저드 페널티의 영향이 더욱 심각하다는 것을 알 수 있다.

 

그럼 여기서 만약 무조건 분기 명령의 페널티를 없애기 위해 명령어 인출 단계에 HW를 추가한다면?

디코더는 명령어 인출 단계에서 무조건 분기 명령어를 식별하고, 가산기는 분기 주소를 계산하기 위해 추가했다고 가정해보자. 

이때 HW를 추가함으로써 명령어 인출 단계의 지연시간이 2ns에서 3ns가 되었다고 가정하자.

또한 전체 분기 명령어 17% 중 6%가 무조건 분기 명령어라고 가정하자.

 

기존의 CPI는 1 + 0.17*3 = 1.51 이고

추가후 CPI는 1 + 0.11*3 = 1.33 이다.

 

이제 프로그램 실행 시간을 구해보면 ( 프로그램 실행시간 = 명령어 개수 * CPI * 사이클 시간)

 

기존 프로그램 실행 시간 = 명령어 개수 (n이라 가정) * 1.51 * 2ns = 3.02n

추가 후 프로그램 실행 시간 = 명령어 개수(똑같이 n) * 1.33 * 3ns = 3.99n

 

즉 성능은 기존 프로그램이 더 좋음을 알 수 있다.

따라서 이 가정대로라면 HW를 추가하는 게 바람직하지 않다. 

 

 

해저드의 해결 방법

 

정적인 방법 : 잠재적 해저드 분석, 원인 제거 -> HW 추가, 코드 재배치(컴파일러)

-> 프로그램이 수행되기 전, 해저드가 발생할 수 있을 만한 명령어를 조치

 

동적인 방법 : 해저드 발생 시, 원인이 제거될 때까지 다음 명령어의 수행을 연기

-> 프로그램이 실제로 수행되는 과정에서 다음 명령어 수행을 임시로 중단하거나, 아무 동작을 하지 않는 "nop" 명령으로 파이프라인을 채움

 

위의 두 가지 방법은 뚜렷한 단점이 존재한다.

HW 추가는 개발비용을 증가시키고, Nop 명령어 추가는 성능을 저하시킨다.

 

그럼 이런 기본적인 해결 방법보다 더 좋은 방법은 없을까?

(당연히 있겠죠..? 아래를 보면 알겠지만 더 좋은 방법이라기 보단 기본적인 해결 방법을 더 빠르게 해 주는? 그런 부가적인 사항들이라고 하는 게 맞을 것 같네요..)

 

구조적 해저드 해결 방법 : 하드웨어 추가/분할, 예약표, 입출력 포트의 다중화 등

 

• IF 단계의 PC 값 증가는 간단한 adder를 추가해서 해결
• IF-MEM 단계의 메모리 접근 충돌은 명령어 메모리와 데이터 메모리로 나누거나, 별도의 Cache 메모리를 두어 해결
• ID-WB 단계의 레지스터 접근 충돌은 시분할 R/W 접근 혹은 멀티포트 레지스터 사용
• 자원 충돌 가능성이 있는 단계의 파이프라인 재구성(파이프라인 추가)하거나, 예약표 방식을 통해 충돌 방지
• 기다려야만 하는 경우, 해당 클럭 사이클 동안NOP(Bubble) 명령어 삽입, 수행
• Nop 명령어: 아무 일도 안 함(Python 등 프로그래밍 언어에서 Null 값과 유사한 역할)

많은 방법들이 있지만 말 그대로 하드웨어 추가/분할, 예약표, 입출력 포트의 다중화를 통해 해결한다.

 

 

데이터 해저드 해결방법 : 전방 전달과 지연 적재

 

데이터 해저드는 주로 RAW라고 앞에서 공부했다.

이때 RAW 해저드는 계산 후 읽기 해저드, 적재 후 읽기 해저드 이 두 가지로 나뉘는데

계산 후 읽기 해저드는 선행 명령어가 ALU를 사용하여 연산한 직후부터 연산 결과를 알 수 있고,

적재 후 읽기 해저드는 선행 명령어가 메모리에 접근한 직후부터 메모리의 내용을 알 수 있다.

즉 선행 명령어가 작업을 끝낼 때까지 후행 명령어가 기다릴 필요가 없다.

 

이렇게 RAW 해저드에 의한 영향을 줄이기 위해 결과를 생성하는 파이프의 출력과 결과를 사용하는 파이프의 입력을 연결하는 별도의 경로를 추가하면 되는데 이를 전방 전달 (forwarding) 기법이라고 한다.

 

X를 ALU, M을 메모리 접근이라고 생각해보면

각 단계가 끝나고 새로운 데이터 경로를 통해 다시 ALU입력으로 넣을 수 있다.

 

또 다른 방법으로는 앞에서 언급한 정적인 방법 중 컴파일러의 코드 재배치 방법이 있는데,

이는 컴파일러가 코드를 읽으며 해저드가 발생할 것 같은 명령어를 최대한 순서를 바꾸어 시간(clock cycle)을 벌어준다.

 

 

명령어 해저드 해결 방법 : 지연 분기와 분기 예측

 

명령어 해저드는 주로 분기 명령어 때문에 발생한다.

분기 명령어는 분기 페널티에 해당하는 사이클만큼 파이프를 낭비한다.

이와 같이 낭비되는 파이프를 분기 지연 슬롯이라고 한다.

 

지연 슬롯을 분기 명령어와 관계없는 명령어로 채운다면 명령어 해저드의 영향을 줄일 수 있다. 

이게 뭔 소린가 했는데 쉽게 생각해보면

어차피 낭비되는 파이프에 다른 명령어를 담아서 실행시키면 실행시간이 단축된다는 것이다.

 

말로만 들으면 좋아 보이지만 아래와 같은 단점이 존재한다.

• 컴파일러가 2개 이상의 분기 지연 슬롯을 채우기 어렵다.
• 지연 적재와 마찬가지로 지연 슬롯에 채워진 명령어는 실제 프로그램 순서와 다르다. 따라서 인터럽트와 같은 돌발적인 상황이 발생할 경우 매우 복잡해진다.

어쨌든 이런 방법이 지연 분기 방법이고 반복문의 경우에 유용하다고 한다.

 

다음으로 분기 예측이다.

분기 예측은 크게 정적 분기 예측과 동적 분기 예측으로 나뉜다.

 

정적 분기 예측은 컴파일러의 도움으로 분기 여부를 예측하는 기법으로 분기가 발생하지 않는다(즉 분기가 실패한다)고 가정하는 무발생 예측 기법과 분기가 발생한다(즉 분기가 성공한다)고 가정하는 발생 예측 기법이 있다.

 

(1) 분기가 실패할 것으로 예측 (predict the branch as not taken)

• 분기가 일어나지 않을 것으로 예측하고 실행
• 분기 주소는 “ID” 단계에서 미리 계산 -> ID : Instruction Decoding 단계
• 만약 분기가 일어나면, 파이프라인을 멈춘 뒤 분기 주소로 이동

(2) 분기가 성공할 것으로 예측 (predict the branch as taken)

• 분기 주소는 “ID” 단계에서 미리 계산
• 예상 페널티: 1 사이클 (실제로 분기 안 함), 1 사이클 (실제로 분기) -> 장점이자 단점임. 무조건 1사이클

동적 분기 예측은 과거 이력에 따라 결정하는 방법이 있는데 자세히 다루지 않는다.

 

 

인터럽트

 

인터럽트 : 프로그램 실행 중 예상하지 못하였으나 발생한 사건

• 실행 중 오류 발생, 입출력 작업의 완료, 사용자나 다른 프로그램 등에 의한 의도적 중단
• 외부 인터럽트: 정전, 파워 이상 등 기계적 고장, 키보드의 인터럽트 키(Crt+Alt+Del) 입력 (사용자의 의도적 행위), 입출력 장치의 데이터 전송 요구나 전송 완료 (I/O 인터럽트) 등
• 내부 인터럽트: 잘못된 명령이나 잘못된 데이터 사용, 프로그램 수행 중 발생 (Division by zero, over/under-flow, exception) 등
• SW인터럽트 : 사용자가 프로그램을 실행시키거나 supervisor 호출 수행, 다른 프로세스 실행시키면서 시분할 처리를 위한 자원 할당 등 수행

참고할 만한 내용이라고 하셔서 읽어봤는데.. 참고만 하는 걸로!

 

 

공격적 파이프라이닝

 

파이프라이닝을 사용하면 이론적으로는 CPI가 1이 되어야 한다.

하지만 해저드 같은 여러 가지 이유로 CPI > 1 임을 알 수 있다.

 

따라서 이런 점들을 어떻게 해결해야 CPI가 1이 되도록, 즉 성능 향상이 되도록 할 수 있을까?

 

그에 대한 해결책이 명령어 레벨에서의 병렬성(ILP) 증가이다.

 

 

위 그림과 같이 3가지 경우가 있다.

 

슈퍼파이프라이닝은 파이프라인의 각 단계의 클록 주기를 절반 이하로 줄여서(단계 수 늘림) 명령어의 실행 속도를 2배 이상 향상하는 기술이다.

즉 슈퍼파이프라이닝은 파이프라인의 각 파이프를 다시 파이프라인 화하여 성능을 개선한다.

그럼 슈퍼파이프라이닝이 무조건 좋은가? 그건 아니다.

 

• Clock skew 현상이 심화 가능
• 파이프라인의 해저드 문제 발생률이 더 높아지고, 해저드에 따른 성능 페널티가 높아짐 
• 클럭이 높아짐에 따라 클럭 주기를 더 작게 나누기 힘듦
• 클럭 속도 상승은 발열 문제 발생시킴
• HW 설계가 어려움

사실 당연한 이야기들이다. 단계를 나누려면 HW적 지원이 필요할 것이고, 하는 일이 더 많다면 해저드가 발생했을 때 복구해야 될 것들이 많다는 이야기이기도 하다.

 

슈퍼스칼라 파이프라이닝은 파이프라이닝과 병렬 처리를 혼합한 형태로 동시에 2~4개의 서로 독립적 명령어를 이슈 가능하게 한다.

정적 스케쥴링과 동적 스케쥴링을 함께 사용한다.

 

• 명령어의 기본적인 독립성은 컴파일러의 도움을 받음
• 실행 중 동적(dynamic)으로 의존성을 검사해 독립적 명령어들은 동시에 issue 하고, 의존성이 있으면 순차 수행
• 최대한 많은 명령어를 수행하기 위해 out-of-order 수행

쉽게 말하면 같이 실행해도 문제없는 명령어들끼리는 최대한 같이 수행하고 그렇지 않으면 순서대로 하겠다는 말이다.

 

이것도 말로만 들으면 좋아 보이지만 단점이 존재한다.

 

• 명령어 스케쥴링이 매우 복잡
• 컴파일러의 로직도, HW 설계도 다 복잡

단점이 확실하지만 성능 향상 부분에서는 확실하기 때문에 오늘날 대부분의 컴퓨터가 사용하고 있다고 한다.

 

 

VLIW(Very Long Instruction Word) 구조

 

(그림을 보고 이해하는 게 제일 좋을 것 같다.)

• 프로세서 내에 여러 개의 실행 장치 (ALU 등)를 가짐
• 한 명령어 워드 내에 실제로는 여러 개의 연산 코드와 피연산자를 집어넣어 명령어 실행 시 각각 별도의 실행 장치에서 실행함으로써 병렬성은 높이려고 시도
• 동시 실행 가능한 명령어는 서로 간 의존성이 없도록 구성

컴파일러에 의한 정적 분석을 통해 독립된 명령어를 찾음으로써 HW적 복잡도는 낮고 발열 문제가 적지만, 컴파일러가 많이 힘들어졌다고 한다.. 

 

주로 특수목적 컴퓨터에서 사용된다고 한다.

 

 

이렇게 파이프라이닝에 대해 알아보았다.

뭔가 지금까지 공부한 이유가 msg 조금 쳐서 파이프라이닝 때문이라고 해도 될 정도로 중요한 챕터인 것 같다.