[컴퓨터 구조] 22. Pipeline MIPS (6) - 성능 측정

Single Cycle MIPS 의 성능을 측정할 때, 간단하게 CPU 성능만 측정했던 내용을 복기해보자.

 

CPU Time = 명령어 개수 x CPI x Clock Cycle Time = inst x CPI / f

 

실행시간은 많은 요인들에 의해 결정이 되지만, 간단하게 CPU의 실행시간만 생각하고 위와 같이 계산할 수 있었다.

 

이 내용을 Pipelined MIPS에 적용해보자.

CPU가 어떤 프로그램을 실행시키는데 1000억개의 명령어를 실행해야 한다면, 이 프로그램의 실행 시간은 얼마가 나올까?

 

우선 이상적으로는 CPI는 1에 수렴할 것이다.

왜냐하면 첫번째 명령어를 실행하는데 5 클럭 사이클이 걸렸다고 하면, 그 다음 명령어는 6번째 클럭 사이클에 실행이 완료되고, 그 다음 명령어는 7번째 클럭사이클에 실행이 완료되기 때문이다.

따라서 1000억이라는 매우 많은 명령어를 실행하는 상황에서는 이상적으로 거의 1에 수렴하게 될 것임을 알 수 있다.

물론 현실적으로 stall 이나 flush가 발생하게 되면, CPI가 증가하여 성능에 악영향을 줄 것이다.

(근데 실제로는 우리가 사용하는 장치가 멀티 코어, many 코어로 가고 있기 때문에 CPI가 1보다 작아지기도 한다고 한다.

물론 지금 보는 것처럼 싱글 프로세서로서 코어가 1개라면 CPI는 1이 최선이다.)

 

다시 예제로 돌아와서 이 CPU로 어떤 벤치마크를 실행하는데, 그 벤치마크 프로그램의 어셈블리 구성이 다음과 같았다고 해보자.

 

그리고 load 명령어 중 40%에서는 load-use 케이스가 발생하고, 25% branch 명령어는 예측에 실패한다고 해보자.

load-use 케이스는 1cycle의 추가적인 패널티가 존재했고, branch도 예측에 실패하는 경우 1cycle의 패널티가 있었다.

또한 jump 명령어의 경우, 반드시 분기가 일어나기 때문에 1 cycle의 flush가 항상 일어난다고 해보자.

 

이제 이 가정하에서 평균 CPI를 구해보자. (사실 CPI는 그 자체로 평균의 의미를 갖고 있긴 하지만)

만약 위와 같은 구성에서 stall 이나 flush가 없다면, CPI는 그냥 1이 될 것이다. (전제에서 1에 수렴한다고 하였으므로)

하지만 load use 케이스나 branch 예측 실패와 같은 케이스를 고려하여 다시 CPI를 계산해보면 아래와 같이 계산할 수 있다.

 

Load, Branch 명령어는 stall 이나 flush 가 없을 경우, 1 Cycle에 실행되고, 있으면 2 Cycle에 실행된다.

따라서

 

load 명령어의 CPI 는 1 * 0.6 + 2 * 0.4 = 1.4 가 된다.

branch 명령어의 CPI 는 1 * 0.75 + 2 * 0.25 = 1.25 가 된다.

jump 명령어는 항상 flush 가 발생하므로 2 cycle이 소모된다.

 

이제 평균 CPI를 구하면 아래와 같다.

 

0.25 * load 명령어의 평균 CPI +

0.1 * store +

0.11 * branch 명령어의 평균 CPI +

0.02 * jump 명령어 +

0.52 * R-type

 

= 0.25 * 1.4

+ 0.1 * 1

+ 0.11 * 1.25

+ 0.02 * 2

+ 0.52 * 1

 

= 1.15

 

---

참고

Exceptions

예외는 CPU 내부에서 발생하는 이벤트이다.

정의되지 않은 OP Code를 실행하거나, 0으로 나누는 연산과 같이 수행할 수 없는 연산, 또는 산술 오버플로우가 발생했을 때 CPU가 발생시키는 이벤트이다. (MIPS는 오버플로우도 예외로 발생시킨다. 아키텍쳐에 따라 오버플로우는 예외로 발생시키지 않기도 한다.)

 

Interrupts

인터럽트는 외부 I/O 디바이스에서 보내는 이벤트(시그널)이다.

예를 들면 키보드 입력, 마우스 이동, 네트워크 카드와 같은 곳에서 보내는 이벤트이다.

원래 하던 일을 멈추고 지금 I/O 장치를 처리하라고 보내는 신호이다.