컴퓨터 구조론 Lecture 1 - 2

D0Lim·2021년 1월 7일

컴퓨터 구조론

목록 보기

2/13

시작하기 전

이 글은 필자가 수업시간에 들은 내용과 강의록을 토대로 정리한 글입니다.
수업 필기이다 보니, 오류가 있거나 설명이 부족한 부분이 있을 수 있습니다.
궁금하신 점이나 지적하실 점이 있다면 댓글로 달아주세요! 확인 후 내용을 추가하거나 답변해드리도록 하겠습니다 :)

반응 시간과 처리율 (Response time and Throughput)

반응시간 (Response Time), 지연 (latency), 실행시간 (execution time)

하나의 작업을 수행하는 데에 얼마나 오래 걸리는가?

처리율(Throughput)

컴퓨터가 한번에 얼마나 많은 작업을 처리할 수 있는가?
단위시간 (unit time) 당 총 작업량

반응시간과 처리율은 어떻게 영향을 받을까?

프로세서를 더 빠른 버전으로 바꾸면?
- 반응시간 $\downarrow$ , 처리율 $\uparrow$
더 많은 프로세서를 추가하면?
- 반응시간 변화 없음, 처리율 $\uparrow$

실제 컴퓨터에서는, 반응 시간이나 처리율의 변화가 서로에게 영향을 미친다. (물어보기)
이 수업에서는 일단, 반응 시간에 조금 더 집중하도록 하자.

성능 비교 (Comparing Performance)

정의

Performance_x = \frac {1} {Execution time_x}

이 수업에서는 반응 시간, 즉 처리 시간에 집중하기로 했기 때문에 성능은 $\frac {1} {Execution time_x}$ 로 나타낼 수 있다.

“X가 Y보다 n배 빠르다”

\frac {Performance_x} {Performance_y} = \frac {Execution\ time_y} {Execution\ time_x} = n

위의 계산식은 꼭 기억하도록 하자.

처리 시간 비교 (Measuring Execution Time)

경과 시간 (Elapsed time)

모든 측면을 포함한 총 실행 시간(프로세싱, I/O 등)
시스템 전체의 성능을 정의한다.
유용하다. 그러나 But, 비교 목적으로는 그닥 좋지 못하다.

CPU 시간 (CPU itme)

CPU가 주어진 작업을 처리하는데에 걸린 시간 (I/O 이런거 빼고)
사용자 CPU 시간(User CPU time)과 시스템 CPU 시간(System CPU time)으로 이루어져 있다.
서로 다른 프로그램은 CPU와 시스템 성능에 각각 다르게 영향을 받는다.
중요하다. 그럼에도 불구하고 …

우리는 우리가 작성한 코드로 돌아가는 프로그램을 처리하는데 걸린 시간, 즉 사용자 CPU 시간 (User CPU time)에 집중하도록 한다. 물론, 가끔은 다른 요소들이 성능에 영향을 미칠 수는 있다.

CPU 클럭 (CPU Clocking)

클럭 (Clock)이란?

디지털 하드웨어(Hardware)는 일정한 속도의 클럭(Clock)에 의해 작동된다.
clock

클럭 진동수(Clock frequency) : 1초 당 반복 수(Cycles per second)
클럭 주기(Clock period)
- 클럭이 위, 아래로 움직일 동안 걸리는 시간이다.
- 간단하게, $\frac {1} {Clock Frequency}$ 이다.
- 변환할 때 단위에 대해서 조심하도록 해야할 것 같다.

클럭과 퍼포먼스(Clock and Performance)

클럭 진동수는 성능에 대한 그 어떤 것도 말해주지 않는다.
그렇기에, 우리는 총 시간(Total time)을 측정해야 한다.

CPU 성능에 영향을 주는 요인들 (Factors for CPU Performance)

성능은 처리 시간에 의해 결정된다.
다음 중 어떤 것이라도 성능의 지표라고 말할 수 있는 것들이 있을까?
- 프로그램을 처리하기 위한 클럭 사이클 수 -> NO
  - 1초에 몇 번 클럭이 진동하는지 알 수 없다.
- 프로그램의 명령(Instruction) 수 -> NO
  - 명령(Instruction) 하나를 처리하는 데에 걸리는 시간을 알 수 없다.
- 초당 클럭 사이클(클럭 진동수) -> NO
  - 클럭 한번에 얼마나 많은 명령(Instruction)을 처리할 수 있는지 알 수 없다.
- 명령(Instruction) 당 평균 클럭 사이클 수 -> NO
  - 클럭 한번에 얼마나 긴 시간이 걸리는지 알 수 없다.
- 초당 처리할 수 있는 명령(Instruction)의 수 -> NO
  - 그 명령(Instruction)이 어떤 명령인지 알 수 없다. 예를 들어, CPU A는 곱셈을 지원하고 B는 그렇지 않다고 가정하면, 명령은 매우 많은 차이를 보일 것이다.

CPU 시간 (CPU Time)

\mathrm {CPU \ Time} = (\mathrm {CPU\ Clock\ Cycles}) \times (\mathrm {Clock\ Cycle\ Time})

= \frac {(\mathrm {CPU\ Clock\ Cycles})} {(\mathrm {Clock\ Rate})}

성능은 다음에 의해 향상될 수 있다.
- 클럭 사이클 수를 줄이는 것
- 시간당 클럭 사이클 수를 높이는 것

위의 두 가지는 서로 종속적이기 때문에, 하드웨어 디자이너는 종종 클럭 속도와 클럭 사이클 수 사이에서 결단을 내리게 된다.

명령 수, CPI 그리고 성능 (Instruction Count, CPI and performance)

어떤 프로그램의 명령 수

프로그램, 컴파일러 그리고 ISA에 의해 결정된다.

평균 CPI

CPI는 Clock Per Instruction의 약자이다.
명령(Instruciton)마다 CPI가 다른 상황이 종종 생기기 때문에 평균 CPI를 사용한다.
그 때문에 명령 집합(Instruction mix)의 영향을 받는다.
즉, Same ISA + Same program, compiler $\rightarrow$ SAME Instruction count 이다.
또한, CPU 하드웨어에 영향을 받는다.

항상 구하는 것이 평균 CPI 라는 것을 잊어서는 안된다.

CPI에 따른 성능

(\mathrm {Clock\ Cycle}) = (\mathrm {Instruction\ Count}) \times \mathrm {CPI}

이기 때문에,

\mathrm {CPU\ Time} = (\mathrm {Instruction\ Count}) \times \mathrm {CPI} \times (\mathrm {Clock\ Cycle\ Time})

= \frac {(\mathrm {Instruction\ Count}) \times \mathrm {CPI}} {(\mathrm {Clock\ Rate})}

이다.

CPI에 대하여 (CPI in more detail)

만약 다른 명령 클래스들이 다른 수의 사이클을 필요로 한다면

(\mathrm {Clock\ Cycles}) = \sum_{i=1}^n {({\mathrm {CPI}}_i \times {\mathrm {Instruction\ Count}}_i)}

이다.

전력의 추세 (Power Trends)

fckiyzf

<출처 : http://www.brainkart.com/article/Computer-Architecture--Power-Wall_8606/>
최근에는 전력이 클럭 주파수(Clock rate)보다 더 중요해지고 있다.
즉, 어떻게 하면 사용 전력을 줄일 수 있는가가 큰 관건이라는 뜻이다.

CMOS IC 테크놀로지에서는

\mathrm {Power} = \frac {1} {2} \times \mathrm {Capacitive Load} \times {\mathrm {Voltage}}^2 \times \mathrm {Frequency}

이다.

이를 간단히 해석해보면, 전력은 용량성 부하(Capacitive Load)에 비례하고, 전압의 제곱에 비례하며, 주파수에 비례한다.
용량성 부하는 전기 공학에서 다루는 용어라서 매우 중요한 내용은 아니다. 간단하게, 트랜지스터에 무유도 저항(저항이 같은 ‘그 저항’)이 아니라 유도 저항을 사용하게 되면, 무유도 저항을 사용할 때와는 다르게 작동한다. 트랜지스터가 꺼져야 할 때, 콘덴서에 의해서 약간의 과부하가 걸리게 되는데, 이를 용량성 부하라고 한다고 한다.

전력을 줄이기 (Reducing Power)

많은 공학자들이 전력을 줄이기 위해 갖은 노력을 기울였을 것이다. 그 결과...

전압(Voltage)
전압은 5 $\rightarrow$ 3.3 $\rightarrow$ 3 $\rightarrow$ 1.5 $\rightarrow$ 1 (V) 로 감소했다.

그러나 이 이상 전압을 감소시키면, 켬(1)과 끔(0) 사이의 경계가 너무 모호해진다.
또한, 전력은 구동에만 쓰이는 것이 아니다. 쿨링에도 쓰인다. 따라서, 여기서 더 전력을 줄이게 되면 필요한 만큼 열을 제거할 수 없게 된다.[^2]
그리하여 공학자들은 다음과 같은 방법을 구상해내게 된다.

파이프라인(Pipelining)
병렬 프로세서(Parallel Processor)

싱글 프로세서 성능 (Uniprocessor Performance)

performance_growth

2003년에 평평해지다가, 2012되면서 더 평평해지는 것을 확인할 수 있다.
이 성능 발전을 막은 것은 전력, 비순차적 명령어 처리의 한계, 메모리 지연 시간이다.

멀티 프로세서 (Multiprocessors)

수업 시간에 설명하지는 않으셨지만, 멀티 프로세서를 구현하는 방법은 다양하다.
한 프로세서에 여러개의 코어를 박는 것(Multicore)와 한 메인보드에 여러개의 CPU를 박는 것(예를 들어 Dual CPU)[^3] 등이 있다.

멀티코어(Multicore)
하나의 CPU 칩에 여러 개의 코어를 박는 것이다.
이 방법은 명시적인 병렬 프로그래밍을 필요로 한다.
- 비순차적 명령어 처리와 비교해보면..
  - 멀티 프로세서에서는 '실제로' 한번에 여러개의 명령(Instruction)이 처리된다.
  - 멀티 프로세서를 위한 프로그래밍은 프로그래머에게 어떤 일이 일어나는지 알려져 있지만, 비순차적 명령어 처리는 프로세서 내부에서 이루어지기 때문에 프로그래머에게는 숨겨져있다.
- 즉, 프로그래머가 멀티코어를 지원하기 위해서 직접 프로그래밍을 해주어야 한다.
  - 알아서 멀티코어로 처리하도록 컴파일러를 작성하는 것은 너무 복잡하기 때문이다.
- 결국 프로그래밍이 상당히 복잡해진다.
  - 그래도 성능이 중요한 프로그래밍에는 필수적이다.
  - 동시에, 코어들 간에 균형을 맞추는 데에도 필요하다. 싱글코어 프로그램에 멀티코어 프로세서를 쓰면 하루종일 Core0만 열일하고 있을 것이다.
그러나 일단 이 수업에서는 싱글 프로세서의 처리에 집중하도록 하자.

D0Lim

이전 포스트

컴퓨터 구조론 Lecture 1 - 1

다음 포스트

컴퓨터 구조론 Lecture 1 - 2