[CSAPP] Pipelining - Performance

1. 성능 평가

1-1. 서론 (Introduction)

CPU의 성능은 크게 두 가지 측면에서 평가할 수 있다. 하나는 서버(Server)의 입장에서 평가하는 것이고, 다른 하나는 클라이언트(Client)의 입장에서 평가하는 것이다. 예를 하나 들어 보자. 서울에서 부산까지 1시간 만에 가는 자동차 A가 있고, 30분 만에 가는 자동차 B가 있다고 해보자. 그런데 자동차 A는 20명을 태울 수 있고, 자동차 B는 5명만 태울 수 있다고 해보자. 그러면 탑승자 각각의 입장에서는 당연히 30분 만에 갈 수 있는 자동차 B가 더 좋다. 그러나 운전자의 입장에서는 1시간 동안 20명을 태워다 줄 수 있는 자동차 A가 1시간 동안 10명만 태워다 줄 수 있는 자동차 B보다 더 좋다. 이러한 측면에서 파이프라인 방식의 성능을 평가해 보면, 파이프라인 방식은 SEQ 방식과 비교했을 때 클라이언트의 입장에서는 그다지 큰 성능의 향상을 가져다주지 못하지만, 서버의 입장에서는 엄청난 성능의 향상을 가져다준다. 예를 들어, SEQ 방식에서 한 명령어를 처리하는 데 걸리는 시간, 즉 한 사이클이 10초였다고 해보자. 그리고 파이프라인 방식에서는 한 사이클을 1초로 두고 한 명령어를 처리하는 데 열 사이클이 소요되도록 했다고 해보자. 그러면 각 명령어의 입장에서는 실행이 완료되는 데까지 걸리는 시간이 똑같이 10초이므로 별다른 성능의 향상이 없다. 그러나 CPU의 입장에서는 10초에 하나의 명령어를 처리할 수 있었던 것을, 10초에 열 개의 명령어를 처리할 수 있게 되므로 엄청난 성능의 향상을 이루게 된다.

---

1-2. 시간 (Time)

프로그램 실행이 시작된 시점부터 끝나는 시점까지 소요되는 총시간을 응답 시간(Response Time, Wall-clock Time, Elapsed Time)이라고 한다. 이것은 자기 자신의 코드를 비롯한 다른 프로그램의 코드 또는 OS의 코드를 실행하는 데 CPU가 소요하는 시간, 입출력에 소요되는 시간, 그 외 시스템 오버헤드 등을 모두 포함한다. 그리고 이 중에서 실제로 자기 자신의 코드와 OS의 코드를 실행하는 데 CPU가 소요하는 시간을 CPU 시간(CPU Time) 또는 실행 시간(Execution Time)이라 부른다. 우리가 중요하게 다룰 것은 실행 시간으로, 이를 공식으로 나타내면 다음과 같다.

 

 

위 공식에 근거하여, 실행 시간에 영향을 주는 요소를 표로 분석해보면 다음과 같다. 먼저, 한 프로그램 당 평균 명령어의 개수는 프로그램이 어떻게 짜여 있는가, 프로그램 코드를 컴파일러가 어떻게 번역하는가, 그리고 ISA 체계가 어떠한가에 따라 달라질 수 있다. 그리고 한 명령어 당 소요되는 평균 사이클의 개수를 의미하는 CPI는 ISA의 체계와 CPU의 디자인 방식(SEQ, 파이프라인 등)에 따라 달라질 수 있다. 마지막으로, 한 사이클 당 소요되는 평균 시간은 CPU의 디자인 방식(SEQ, 파이프라인 등)과 성능 향상을 위해 첨가되는 몇 가지 기술에 의해 달라질 수 있다.

 

 

다음은 RISC(Reduced Instruction Set Computer)와 CISC(Complex Instruction Set Computer)의 몇 가지 성능 척도를 여러 벤치마크(성능 평가를 위해 실험으로 사용하는 프로그램)를 기준으로 비교해본 결과를 나타낸다. spice 벤치마크를 기준으로, RISC가 CISC보다 평균 명령어의 개수가 2.5배 많지만, CPI의 경우 한 명령어를 수행하는 데 있어 복잡한 동작을 수행해야 하는 CISC가 RISC보다 약 4.5배 크다. 따라서 RISC와 CISC의 실행 시간은 다음과 같이 계산해볼 수 있다. 결론적으로, RISC가 CISC보다 1.8배 빠른 실행 속도를 보인다.

⇒ RISC 실행 시간 : CISC 실행 시간 = 2.5 x 1 : 1 x 4.5 = 1 : 1.8

 

---

1-3. 속도 (Rate)

위에서 다룬 실행 시간이 클라이언트의 입장에서 평가한 성능이라면, 이번에는 서버의 입장에서 성능을 평가해볼 차례이다. 즉, 주어진 시간 내에 얼마나 많은 작업량을 처리하는지 관찰하는 것이다. 이와 관련된 대표적인 척도는 바로 MIPS(Million Instructions Per Second)로, 1초 당 실행되는 명령어의 개수를 나타낸다. 참고로 유사한 의미의 척도로서 MFLOPS(Million Floating-point Operations Per Second)라는 것도 존재한다.

 

 

의미적으로는 대략 실행 시간의 역수라고 생각할 수 있지만, 꼭 그렇지는 않으니 유의 바란다. MIPS는 가장 이해하기 쉬운 척도로, 일반적으로는 MIPS가 크면 빠른 기계라고 판단할 수 있을 것이다. 그러나 MIPS는 몇 가지 문제를 지니고 있어서 실제 성능과 비례하지 않는 경우도 있다. 먼저, MIPS는 각 명령어의 수행 능력이나 작업량 등을 고려하지 않는다는 것이다. 예를 들어 하나의 명령어가 상당히 많은 작업을 처리할 수도 있는데, MIPS는 단순히 명령어의 개수만 세므로 그 사실이 평가에 전혀 반영되지 않는다. 다음으로, 동일한 컴퓨터 내에서도 성능 평가를 위한 벤치마크로 무엇을 사용하느냐에 따라 평가 결과가 달라질 수 있다는 것이다.

---

1-4. 비율 (Ratio)

동일한 성능 척도에 대해 두 대상을 비교할 때 쓰는 표현들에 대해 간단히 알아보자. 다음과 같이 총 세 가지가 존재한다.

 

---

1-5. 성능 척도 요약 방법 (How to Summarize Performance)

지금까지 언급한 세 가지 성능 척도를 요약하는 방법은 다음과 같다. 실행 시간은 산술 평균으로 요약할 수 있고, MIPS는 조화 평균으로 요약할 수 있으며, 마지막으로 Ratio는 기하 평균으로 요약할 수 있다. 참고로 W_i는 각 벤치마크가 한 번씩 실행되는 것이 아니라 여러 번 실행되는 경우에 필요한 값으로, 각 벤치마크의 실행 횟수를 나타내는 가중치이다.

 

 

2. 벤치마크 (Benchmark)

2-1. 의미

성능을 제대로 평가하기 위해선 성능을 평가하는 객관적 수단이 제대로 마련되어야 한다. 이처럼 특정 성능의 상대적 평가를 위해 표준화된 프로그램들로 테스트를 수행하는 작업, 혹은 그러한 프로그램들을 벤치마크(Benchmark)라고 부른다. 물론 벤치마크는 어떤 것의 성능을 평가하느냐에 따라, 즉 도메인에 따라 여러 종류가 존재한다. 좋은 벤치마크가 되기 위해서는 평가하고자 하는 대상의 의미 있고 중요한 부분들을 놓치지 않고 객관적으로 잘 평가할 수 있도록 표준화되어야 하며, 이를 쓰고자 하는 사람들이 쉽게 이해할 수 있고 받아들일 수 있도록 설계가 되어야 한다.

 

벤치마크는 특정 성능 척도에 있어서 명확한 목표를 제시해주기 때문에, 관련된 공학자들은 그 목표에 조금이라도 더 가까이 가기 위해서 여러 가지 성능 개선을 시도하게 된다. 즉 벤치마크는 기술의 빠른 발전을 자극하는 원동력이 되는 셈이다. 하지만 하나의 벤치마크는 그리 오래가지 못한다. 처음 발표되었을 때는 많은 사람들에게 동기를 부여하여 빠른 발전을 자극한다. 하지만 시간이 어느 정도 지나면, 그 목표를 달성하기 위한 합리적인 방법들이 수없이 고안이 되어 더 이상 합리적인 방법으로는 발전하기 어려운 시점에 도달한다. 이때부터는 그 벤치마크에만 맞아떨어지는 일종의 '꼼수'를 부리면서 테스트 결과 점수를 높이기 시작하는 사람들이 생겨나기 시작한다. 결국 해당 벤치마크의 가치가 점점 하락하고, 새로운 벤치마크의 필요성이 대두되는 것이다.

---

2-2. SPEC (Standard Performance Evaluation Corporation)

현대 컴퓨터들의 성능 평가를 위한 표준화된 벤치마크들을 제공하기 위해 1988년에 설립된 비영리 단체이다. 테스트를 위한 프로그램들을 마련하고, 해당 프로그램들을 어떤 환경에서 어떤 입력 형식으로 어떤 방식으로 실행시켜야 하는지, 그리고 그 실행 시간 관찰 결과를 어떤 규칙으로 보고해야 하는지 등에 대한 규칙들을 전부 확립하였다.

 

다음은 2000년에 발표된 SPEC의 벤치마크를 사용하여 테스트를 수행한 예시이다. 각 벤치마크 프로그램들에 대해, 기준 실행 시간과 테스트 실행 시간의 비율을 계산한다. 그리고 그것들을 기하 평균으로 요약하여 우측 상단에 작성한다. 참고로 회색은 똑같은 컴파일러 및 컴파일러 옵션으로 컴파일한 프로그램을 기준으로 테스트한 결과이고, 하얀색은 그렇지 않은 경우의 테스트 결과에 해당한다.

 

 

다음은 2006년에 발표된 벤치마크이다. 각 벤치마크 프로그램별로 세 번씩 실행하고 중간값을 택하도록 하고 있다.

 

 

다음은 동일한 벤치마크를 사용하여 테스트한 또 다른 예시이다. 바로 위의 테스트 결과와 비교했을 때, 여기서 사용하는 CPU는 옥타 코어임을 유추해볼 수 있다. 실행 속도가 대략 8배 빨라졌기 때문이다.

 

 

3. 암달의 법칙 (Amdahl's Law)

3-1. 정의

암달의 법칙(Amdahl's Law)은 특정 부분의 개선에 의한 전체적인 성능의 향상 정도는 그 개선된 부분이 사용되는 부분의 양에 의해 제한된다는 것을 의미한다. 예를 들어, 기술 A를 사용하는 컴퓨터에서 어떤 프로그램의 전체 실행 시간은 100이고 그중에 20은 기술 A에 의해 영향받는 부분이라고 해보자. 그러면 기술 A를 아무리 좋게 개선하더라도 그 프로그램의 전체 실행 시간은 80보다 줄일 수 없다. 기술 A에 의해 영향받는 20을 0으로 만든다 하더라도 기술 A에 영향을 받지 않는 80은 절대 변하지 않기 때문이다.

 

실행 시간(Execution Time)에 암달의 법칙을 적용하면 다음과 같은 공식이 도출된다.

 

---

3-2. 예시

어떤 프로그램이 실행하는 데 100초 걸리는 컴퓨터가 있다고 해보자. 그리고 곱셈 연산이 차지하는 비중은 80초라고 해보자. 이때 곱셈 연산을 기존보다 n배 빠르게 수행할 수 있도록 개선한다면, 해당 프로그램의 총 실행 시간은 다음과 같이 표현될 수 있다.

⇒ 개선 후 실행 시간 = (80초 / n) + (100초 - 80초)

 

따라서 n이 아무리 크더라도(곱셈 연산을 아무리 좋게 개선하더라도) 해당 프로그램의 실행 시간은 20초보다 줄일 수 없다. 곱셈 연산에 영향을 받는 시간이 전체 중에 80초이기 때문이다.

 

다음 그림은 암달의 법칙을 나타내는 또 다른 예시이다.