[CA] ILP - Introduction

명령어 실행 성능을 높이기 위해 명령어의 실행 순서를 바꾸는 것.

 

ILP(Instruction Level Parellelism)

명령어들을 병렬적으로 실행하는 것.

Pipelining, Out of Order Execution, Multiple Issue 등이 해당한다.

 

ILP를 높이기 위한 방법

하드웨어를 통한 기법과 소프트웨어를 통한 기법이 있다.

이 둘은 서로 독립적이 아니라 상호보완적인 성질을 가지고 있다.

 

어느 하나의 방법만 사용하는 것이 아니라 여러 방법을 조합하여 최적의 성능을 뽑아내려고 하는 것이

컴퓨터 아키텍처를 연구하는 사람들의 목표

 

ILP를 제한하는 Dependency

이러한 Dependency는 transitive해서 B가 A에 의존하고 C가 B에 의존하면 C도 A에 의존하게 된다.

 

Out of Order Execution이 필요한 이유

for (i = 999; i >= 0; i = i - 1)
    x[i] = x[i] + s;

Loop:   fld f0, 0(x1)      // f0 = array element
        fadd.d f4, f0, f2  // add scalar in f2
        fsd f4, 0(x1)      // store result
        addi x1, x1, -8    // decrement pointer 8 bytes
        bne x1, x2, Loop   // branch x1 != x2

C코드를 Mips 어셈블리어로 변환.

 

f0을 로드 한 후에 더할 수 있고,
f4에 쓴 다음에 스토어 할 수 있는 명령어들 사이의 의존성이 존재한다.

 

그러나 각 루프들 사이에는 의존성이 존재하지 않는다!

 

True data dependency

Bypassing이나 Forwarding을 사용해서 해결했다.

 

Antidependency

만약 L4가 L3보다 먼저 실행되면,

L3가 실행 할 때 계산된 주소가 달라진다. 

 

Output dependency

첫 번째 명령어와 두 번째 명령어 모두 f4에 값을 저장하지만,

둘 중 누가 먼저 실행되는지에 따라 결과가 다르다.

 

Control dependency

모든 명령어는 한 개 이상의 브랜치에 의존한다. (dependency의 transitive)

 

Multi-FU(Functional Unit) Pipeline

부동 소수점 연산은 정수 연산보다 시간이 오래 걸린다.

따라서 부동 소수점 연산이 파이프라인화되지 않았을 때, 만약에 하나의 연산이 곱셈 유닛을 점유하면,

다음 연산은 대기해야 한다.

 

이를 해결하기 위해 EX를 파이프라인화 한다.

그러나 나눗셈 연산은 파이프라인화 되지 않았다.

 

파이프라인의 우려

1. 구조적 해저드 발생 가능성: 나눗셈 유닛이 파이프라인화되지 않으면 구조적 해저드가 발생할 수 있다.
2. 한 사이클에 필요한 레지스터 쓰기 수: 한 사이클에 필요한 레지스터 쓰기의 수가 1보다 클 수 있다.
3. WAW 해저드의 가능성: 명령어가 더 이상 프로그램 순서대로 WB(Write Back) 단계에 도달하지 않기 때문에 WAW(Write After Write) 해저드가 발생할 가능성이 있다.
4. 명령어 완료 순서의 불일치: 명령어가 발행된 순서와 다른 순서로 완료될 수 있으며, 이는 예외 처리에 문제를 일으킬 수 있다.
5. RAW 해저드로 인한 스톨 빈도 증가: 연산의 지연 시간이 길어지면서 RAW(Read After Write) 해저드로 인한 스톨이 더 빈번하게 발생할 것이다.

Load는 메모리 단계에서 데이터를 로드하고, Multiply는 해당 데이터를 읽어야 한다.
따라서 포워딩을 통해 데이터를 전달해도 스톨이 발생한다.
Multiply는 결과를 Add 명령어에 전달해야 하므로, Add 명령어도 스톨이 발생한다.
Store 명령어도 메모리 사이클을 거쳐야 하므로 추가적인 스톨이 발생한다.