[Computer Architecture] CPU 성능 향상을 위한 기법 ② -Instruction pipelining, Superscalar, OoOE

⚠️ 공부한 내용을 정리하는 공간입니다. 설명이 부족하거나 옳바르지 못한 부분이 있을 수 있습니다. 옳바르지 못한 내용을 발견하셨다면 댓글로 알려주시길 부탁드립니다. 수정하도록 하겠습니다.

 

오늘의 사족

집에 있는데도 집에 가고 싶습니다.

 

 

< 목차 >
1. CPU가 명령을 더 효율적으로 처리할 수 있게 하는 기법-ILP; Instruction-Level Parallelism
   1-1. Instruction Pipelining
     1-1-1. Pipeline Hazard
   1-2. Superscalar
   1-3. OoOE; Out-of-Order Execution

 

 

1. CPU가 명령을 더 효율적으로 처리할 수 있게 하는 기법 - ILP; Instruction-Level Parallelism

이전 글에서는 CPU의 성능을 향상시키기 위한 설계 단계에서의 기법(클럭, 코어, 스레드)들을 알아봤다.

[Computer Architecture] CPU 성능 향상을 위한 기법 ① - Clock, Core, Thread

 

 

아무리 CPU에 코어와 스레드가 많고 클럭 속도가 빠르다 하더라도 명령을 처리하는 데 있어서 비효율적으로 수행한다면 고성능 CPU는 말짱 도루묵이 되어버리고 만다. CPU가 쉬는 일 없이 효율적으로 작동할 수 있도록 하는 일도 매우 중요하다. 이번 글은 어떻게 CPU가 효율적으로 명령을 처리하는 가에 대한 기법을 알아보고자 한다.

 

명령어를 동시에 처리하여 CPU가 쉬는 일 없이 작동시키는 기법을 ILP(명령어 병렬 처리 기법)이라 한다. 명령어를 병렬로 처리할 수 있게 하는 기법들 중에서 대표적인 기법이 앞으로 설명할 Instruction Pipelining, Superscalar, OoOE 기법이다.

 

1-1. Instruction Pipelining (명령어 파이프라이닝)

명령어 파이프라인에 대해 알아보기 전에 파이프라인은 무엇인가에 대해 알 필요가 있다. 파이프라인은 어떠한 업무를 수행/처리하는데 있어서의 단계/절차를 의미한다. 이전에 CPU가 명령어를 어떻게 처리하는가에 대한 글에서 CPU는 명령어를 'Fetch → Decode → Execute' 과정을 반복하면서 수행한다고 했다.

 

그렇다면 다음과 같이 CPU는 한 명령어를 끝마치고 다음 명령어를 실행하는 과정을 반복한다.

 

파이프라인을 사용하지 않고 명령어를 순차적으로 처리하는 경우

 

 

이때  CPU는 명령어를 수행하는 단계(Fetch, Decode, Execute)별로 사용하는 레지스터가 다르다. 그렇다는 건 파이프라인을 사용하는 경우에 단계가 겹치지만 않는다면 CPU는 각 명령어 사이클을 동시에 실행할 수 있다. 이제 더이상 명령어가 끝날 때까지 기다릴 필요가 없어졌다.

Instrcution Pipelining

 

확실히 Instruction Pipelining을 사용하면 순차적으로 명령을 처리할 때보다 더 적은 시간에 더 많은 명령을 수행할 수 있으므로 CPU를 더욱 효율적으로 사용 가능하다.

 

 

1-1-1. Pipeline Hazard

그런데 Instrcution Pipelining이 항상 성능 향상의 결과를 가져오는 것은 아니다. 특정 상황에서는 성능 향상에 실패하는 경우도 있는데 

그 경우를 Pipeline Hazard(파이프라인 위험)이라 한다. 파이프라인 위험으로 데이터 위험, 제어 위험, 구조적 위험이 있다.

 

Pipeline Hazard

 

Data Hazard (데이터 위험)

 

명령어 간 데이터 의존성에 의해 발생하는 위험이다. 데이터 의존적인 두 명령어를 동시에 실행하려고 하면 파이프라인이 제대로 작동하지 않게 되는데 이 경우를 데이터 위험이라고 한다.

 

Control Hazard (제어 위험)

 

주로 분기 등으로 인해 PC에 갑작스러운 변화가 생기는 경우에 발생하는 위험이다. 이 경우에는 분기 예측이라는 기술을 사용하여 막을 수 있다.

 

Structural Hazard (구조적 위험) = Resource Hazard (자원 위험)

 

명령어들을 동시에 실행하는 과정에서 서로 다른 명령어가 동시에 CPU 부품(ALU, Register...)을 사용하려고 할 때 발생하는 위험으로 자원 위험이라고도 불린다.

 

 

1-2. Superscalar

CPU 내부에 여러 개의 명령어 파이프라인을 포함한 구조를 Superscalar라고 한다.

Superscalar

Superscalar는 한 번에 두 개의 명령어를 동시에 처리하기 때문에 Superscalar 구조로 명령어를 처리하는 CPU를 Superscalar Processor, Superscalar CPU라고 한다. Superscalar CPU는 매 클럭 주기마다 동시에 여러 명령어를 Fetch, Decode, Execute할 수 있어야 한다. 그래서 이 방식을 차용한 CPU는 단일 파이프라인으로 구현된 방식보다 파이프라인 위험을 피하기 더욱 까다롭기 때문에 신중하게 설계되어야 한다.

 

 

1-3. OoOE; Out-of-Order Execution

이전 기법들은 메모리에 올라온 명령어를 순서대로 처리하는 순차적 처리방법이었다면 OoOE 기법은 명령어를 비순차적으로 처리하는 기법이다. 보통 언제 명령어를 비순차적으로 처리할 필요가 있을까?

 

Instruction 1) 메모리 1번지에 10 저장
Instruction 2) 메모리 2번지에 15 저장
Instruction 3) 메모리 3번지에 메모리 1번지에 저장된 값과 2번지에 저장된 값을 더한 값을 저장
Instruction 4) 메모리 10번지에 3 저장
Instruction 5) 메모리 11번지에 5 저장

 

위와 같이 명령어가 주어지면 순차적으로 명령을 처리하는 파이프라인의 경우 다음과 같이 처리할 것이다.

 

Instruction 3을 처리하기 위해서는 Instruction 1과 Instruction 2의 값이 저장된 상태여야하기 때문이다. 즉 Instruction 3은 데이터 의존성이 있기 때문에 순차적으로 처리하는 과정에서 시간적으로 딜레이가 생긴다.

 

이때 비순차적 명령어 처리 기법인 OoOE의 경우는 다음과 같이 명령을 처리한다.

OoOE

 

데이터 의존성이 필요한 명령어를 뒷 순서로 보내면 효율적으로 명령 처리가 가능하다. 이처럼 OoOE 기법은 순서를 바꾸어 실행해도 상관없는 명령어를 먼저 실행하여 파이프라인을 멈추는 것을 방지한다. OoOE기법을 차용하려면 CPU가 명령어간 데이터 의존성을 판단할 수 있어야만 한다.

 

그렇다면 어떻게 명령어가 어떤 명령어와 데이터 의존성을 가지고 있는지를 CPU가 어떻게 판단하는지에 대한 의문이 생긴다. 이에 대한 내용은 다음에 알아보자.