[컴퓨터 구조] 3. Performance와 CPU Time

Review)

• performance(speed): clock frequency
• area(cost):
  • 이는 design에서 줄일 수 있는 part가 있고 공정(fab)에서 줄일 수 있는 part가 있는데 데이터가 많이 들어간다고 해서 문제가 되지는 않는다.
  • 더 중요한 문제는 fab, 즉 어떤 공정을 쓰느냐이다.
• power(energy) = power ∝ V_dd² * f * C_L

위 3가지의 tradeoff를 잘 고려하여 부품을 만들어야 함.

 

 

성능 지표

• perf.(speed) = 1 / exec_time
• latency(Time to execute a program)
  • exec_time라고도 하고, throughput이라고도 하지만
  • 당분간은 exec_time으로 정의를 할 것이다.
• exec_time = sec/prog. (한 프로그램당 몇초가 걸리는가)

 

실행 시간(Execution Time)

Exec_Time(sec/prog) = (# of instruction / prog ) * (# of clocks/inst) * (sec/clock)

• 위 식을 약분하여 sec/prog가 나오는 것이다.
• sec/clock(한 클락을 정의하는 시간) => 1 / clock frequency(얼마나 빠른 clock을 쓸 수 있는가)

 

• 1. # of instruction / prog => 프로그램당 얼마나 많은 instruction을 포함하는가?
• 2. # of clocks/inst => instruction 당 몇 개의 clocks을 지나는가?(CPI, Clocks Per Instruction)
  • multi-cycle에서는 average 개념을 도입 - (avg) CPI
• 3. sec/clock => 한 클락당 몇 초인가? = Tc
• 따라서
  • Exec_time = 1. x 2. x 3.

 

• avg.CPI?(Clock per instruction)
  • instruction이 add라는 명령을 수행하는데는 1CLK이 소모되고 multiply 연산을 수행하는데는 10CLK이 사용된다면 이 CPU의 CPI는 무엇인가? 라고 했을 때 대답하기 애매하기 때문에 이를 평균내서 비교가능하도록 수치를 정하는 것이다.
  • IPC = 1/CPI
    • 요즘은 한 클락안에 parallel로 여러 instuction을 수행하기 때문에 IPC를 고려하는 경우도 많아졌지만 일단은 CPI를 고려하도록 할 것이다.

 

MIPS(RISC) 에서는 instruction수가 많고(단순한 명령어로 수행하기 때문에),

x86(CISC)에서는 instruction수가 적은데(복잡한 명령어로 수행하므로) 그렇다고 해서 둘 중 instruction수가 많은 RISC가 무조건 더 비효율적인가? -> 아니다.

 

오히려 간단한 명령어로 구성된 RISC가 더 빠른 성능을 보일 수 있다.

 

clock frequency를 결정하는 것은 중간에 놓인 combinational logic인데 이것이 CISC는 복잡하게 되어 있기 때문에 짧은 clock을 쓰는 것이 어려울 수도 있는 것이다.(짧은 clock 안에 수행하기 어려운 logic인 경우)

---

 

 

Relative Performance(상대 퍼포먼스)

• Performance = 1/Execution Time
• "X가 Y보다 n배 더 빠르다."
  • Performance_X/Performance_Y = Execution time_Y/Execution time_X = n
• Example: 한 프로그램을 실행하는 데 걸린 시간
  • 10s on A, 15s on B
  • Execution TimeB/Execution TimeA= 15s / 10s = 1.5
• A가 B보다 1.5배 더 빠르다.

 

Measuring Execution Time(실행 시간 측정하는 법)

• Elapsed time(경과 시간)
  • 모든 요소를 고려했을 때 총 응답 시간
    
    • Processing, I/O, OS overhead, idle time 등...
  • 시스템 성능을 의미함
  • 모든 것을 고려한 시간
• CPU time
  
  • 주어진 업무를 처리하는데 소비한 시간 
    • Discounts I/O time, other job's shares
  • user CPU time과 system CPU time으로 구성됨
  • CPU와 시스템 성능에 따라 프로그램에 따라 각기 다른 영향을 받음

 

CPU Clocking

• Operation of digital hardware governed by a constant-rate clock

• Clock period(clock cycle time): 한 사이클이 지속되는 시간
  • e.g., 250ps = 0.25ns = 250x10^-12s
• Clock frequency (rate): cycles per second
  • e.g, 4.00GHz = 4000MHz = 4.0 x 10⁹Hz

 

CPU Time

CPU를 설계할 것이기 때문에 이 CPU만 사용하는 데 걸리는 시간이 중요함.

• Performance improved by(성능 향상을 위해선)
  • Reducing number of clock cycles(얘는 조절하기는 힘듦)
  • Increasing clock rate (따라서 combinational logic을 조절하여 성능 개선 시도)
  • 하드웨어 설계자는 종종 clock rate를 cycle 수와 맞바꾸어야 합니다

 

Instruction Count and CPI

• Instruction Count for a program
  • 다음 세 가지에 의해 결정된다program(programming language), ISA(CISC or RISC) and compiler
• Clock Rate = 1/Clock Cycle Time
• Average cycles per instruction (CPI)
  • CPU hardware에 의해 결정됨
  • 여러 instruction이 각기 다른 CPI를 가진다면 
    • 제 각기 다른 instruction의 평균(Average) CPI를 구한다.
• 이를 통해 한 프로그램당 몇 초가 걸리는 지가 나옴

 

CPI in More Detail

• 여러 instruction이 제각기의 cycle수를 갖는다면? -> 평균으로 구함

• Weighted average CPI

 

 

• CPU Time 의 각 term(3가지), 각 term이 무엇에 dependent한지

 

Performance Summary

cf) perf. = 1/CPU_Time

CPU Time = Instructions term x CPI x clock cycle time(T_c)

• Performance는 다음 것들의 영향을 받는다.
  • Algorithm: affects IC(Instruction Count), possibly CPI
  • Programming language: affects IC, CPI
  • Compiler: affects IC, CPI
  • instruction set architecture: affects IC, CPI, T_c, 세가지 전부에 영향을 준다.(그 만큼 중요)
  • Semiconductor
    • 반도체 기술도 T_c에 영향을 주고 CPI에도 영향을 줄 수 있다.

 

Pitfall(함정): MIPS as a Performance Metric

• MIPS: Million of instructions per Second
• 다음을 고려하진 않는다.
  
  • 컴퓨터들 간 ISA의 차이
  • 명령어들 간 복잡도의 차이

• CPI는 주어진 CPU위에서 돌아가는 프로그램들마다 다르다.
• 50 MIPS vs. 100MIPS -> 어떤 명령어(복잡도)를 실행하느냐에 따라 뭐가 더 좋은지가 달라짐
  • 그래서 MIPS만 가지고 성능을 논하기는 힘들다.

 

Power Trends(Power 추세)

• clock rate이 더 이상 오르지 않는 이유는 이를 올릴 수는 있는데 계속 올리다 보면 power에 비례하기 때문에 power가 너무 커져 감당할 수 없는 열이 발생할 수 있기 때문이다.
• power는 30배 증가한 반면 어떻게 clock rate은 1000배 가량 증가할 수 있었을까?
• In CMOS IC technology(Dynamic power)
  • Power = Capacitive load x Voltage² x Frequency
  • power는 30배 증가하고 frequency는 1000배가 늘었지만 제곱하여 비례하는 voltage의 경우 5V에서 1V로 줄었기 때문에 clock rate에 비해 power가 크게 늘어나지 않은 것이다.
• 정리하자면, clock frequency(f)를 늘리고 싶은데 power때문에 못늘리고 있는 상황
  • 그러면 Vdd를 줄이면 되지 않나? -> 이미 5V에서 0.8V까지 줄어든 상황, 거의 한계이다.
  • 그래서 지금 현재 power는 f(requency)와 직결되어 있다고 봐도 무방하다.

 

Reducing Power(power를 줄이는 방법)

• Suppose a new CPU has
• 새 CPU가 다음과 같다고 가정하자. 
  • 85% of capacitive load of old CPU
  • 15% voltage and 15% frequency reduction

• The power wall
  
  • voltage를 더 이상 줄일 순 없다.
  • 더 많이 제거할 수 없다.
• 어떻게 더 성능을 증가할 수 있을까? 
  • => Multi-core로 해결할 수 있다!

 

Uniprocessor Performance(단일 프로세스 성능)

• power 때문에 많이 늘어나지 못함, instruction-level parallelism, long memory latency
• 하지만 게임, 고성능 프로그램 등으로 성능 향상은 반드시 이루어져야 하는 상황이다.
  • 그래서 multi-core가 나타나기 시작

 

Multiprocessors(멀티프로세서)

• 말 그대로 프로세서가 여러개 인 것
• Multi-core microprocessors
  
  • 칩 마다 프로세서가 하나 이상이다.
• multi-core라고 해도 한 processor가 실행될 때 나머지 processors는 놀고 있다. 그래서,
• explicitly parallel programming이 요구된다.
  
  • instruction level의 parallelism과 비교
    
    • 하드웨어는 한 번에 여러 명령어를 실행함
    • 프로그래머에게 숨겨짐
  • 하기 어려운 일
    
    • 성능을 위한 프로그래밍
    • 로드 밸런싱(load balancing)
    • 커뮤니케이션과 동기화 최적화

 

Amdahl's Law

어떤 100초가 걸리는 프로그램이 있다. 이 중 80%는 parallel process를 할 수 있고 20%는 못한다. 근데 10초만에 끝내고 싶다고 해도 결국 parallel processing이 되지 않는 20% 때문에 parallel processing이 불가능할 것이다.

그렇기 때문에 결국 이 20%가 중요하게 작용을 한다. 이를 수식으로 표현하면 다음과 같다.

• 컴퓨터의 어느 한 측면을 개선하고 전반적인 성능에서 그에 비례한 성능을 기대한다.

T_affected : parallelize 가능한 것(parallelizable) -> 1-f

T_unaffected : parallelize 불가능한 것(unparallelizable) -> f

n: 프로세서 개수

• T_n = (1-f) / n + f
• Example: multiply accounts for 80s/100s
  • How much improvement in multiply performance to get 5x overall?

• Corollary(추론): make the common case fast!

 

그래서 T_unaffected가 굉장히 중요한 factor라는 것을 나타낸 것이 Amdahl's Law이다.

• T_unaffected가 bottleneck(병목)