reference: "프로그래머가 몰랐던 멀티코어 CPU 이야기" / 김민장, "Computer System A Programmers'Perspective" / 랜달 E.브라이언트
요즘의 프로세서는 전력을 어마나 절약하는가도 중요한 목표가 되었지만, 전통적으로 컴퓨터의 최고 가치는 속도로 대변된다. 컴퓨터의 속도를 더 정확히 정의하면 한 프로그램을 (1) 얼마나 빠르게 완료하는가 (latency), (2) 단위 시간당 얼마나 많이 처리할 수 있는가 (throughput)로 표현할 수 있다.
다시 말해 프로세서가 주어진 프로그램 기계어를 얼마나 빠르게, 또 얼마나 많이 처리할 수 있는가를 따지는 것과 같다.
프로세서가 명령어 처리 레이턴시를 낮추거나 명령어 처리율을 높이는 방법론은 각각 다르다. 캐시는 대표적으로 레이턴시를 개선하고, 파이프라인은 처리율을 높인다.
source: https://www.dnsstuff.com/latency-throughput-bandwidth
명령어 완료 레이턴시
레이턴시는 응답 시간(response time) 혹은 실행 시간(execution time)으로도 불린다. 프로세서가 어떤 프로그램을 처리하는 데 걸리는 실행 시간은 다음과 같다.
T = N x T_inst
프로그램의 실행 시간
T: 프로그램 전체 실행 시간(초)
N: 주어진 프로그램이 실행한 명령어 갯수(개)
T_inst: 명령어 하나를 처리하는 데 드는 평균 시간(초/개)
물론 현대 운영체제는 여러 프로그램과 백그라운드 서비스가 작동 중이어서 이런 이상적인 공식이 정확히 들어맞지 않음. 그러나 충분히 큰 N이라면 이런 잡음은 무시 가능.
N: 프로그램 실행 명령어 갯수
단순히 프로그램의 정적인(static) 크기가 아닌 실제 동적으로 실행될 떄의 개수이므로 이를 정확히 헤아리려면 프로그램이 실제 입력 값으로 실행될 때 어떤 명령어가 실행되는지 그 트레이스(trace)를 뽑아야 함. 이 작업은 그렇게 어렵지 않음. (이런 작업은 보통 insrtumentation 기법으로 쉽게 구현 가능하다.)
T_inst: 명령어 하나를 처리하는 데 드는 평균 시간
명령어 종류에 따라 수행 시간은 제각각이다. 간단한 예로 정수 사칙 연산은 메모리 연산이나 부동소수점 계산보다 빠르다. 또 프로그램마다 명령어 종류의 분포가 다르다. 따라서 얻어야 하는 정보는 (1) 프로그램에 어떤 종류의 명령어가 얼마나 많이 있는가와 (2) 각각의 명령어 종류가 이 프로세서에서 수행될 때 평균 얼마나 걸리는 가를 알아야 한다.
(1)은 역시 프로그램의 실행 트레이스를 분석해 간단히 알아낼 수 있다. 분기문이 몇 개, 부동소수점 연산이 몇 개 있는지 쉽게 구할 수 있다.
(2)는 프로세서 회사가 자신의 프로세서에 대한 정보를 공개해야만 정확히 알 수 있지만, 실험으로도 어느 정도 추측이 가능하다.
T_inst의 단위는 (초/개)로 주어졌는데 이 값은 프로세서의 클록 속도에 따라 다르므로 보통 시간 차원 대신 사이클을 이용해서 쓰는 것이 편리.
T = N x CPI x T_cycle
CPI를 이용한 프로그램의 실행 시간
CPI(Cycles per Instruction): 명령어당 평균 소요 사이클(사이클/개)를 뜻함.
그런데 명령어당 처리 사이클은 그 종류에 따라 다르므로 이를 고려하여 다음과 같이 쓸 수도 있다.
T = (ΣNi x CPIi) x T_cycle
IPC, MIPS to be continued ..
성능 향상을 위해 해야할 일
T = N x CPI x T_cycle
수식의 세 가지 항 (1) 실행한 명령어 갯수, (2) 명령어 당 사이클 CPI, (3) 클록 속도로 생각
더 빠른 시간을 얻기 위해선 모든 항이 작아지는 방향으로 노력해야하지만 그렇게 하기에는 어렵다. 어떤 항을 개선하면 다른 쪽에 안좋은 영향을 줄 수도 있다.
