Product Development Paradigm
Computer science을 포함한 전반적인 분야에서, 아래 과정이 iterative하게 진행된다.
예를 들어 implementation 개발 중에 interface를 수정/개선해서 다시 진행할 수도 있다.
혹은 테스트 진행 중에 implementation이나 interface을 개선할 수도 있다.
- 시장, 문제, 요구 분석 및 계획
- Design and Implemnetation
- interface : external, 사용자에게 보여지는 부분
- implementation : internal, 내부적인 기능
- 테스트 및 출시
- 지속적인 개선
Computer Science
좋은 성능의 컴퓨터을 개발하기 위해서 development cycle이 iterative하게 동작한다.
더 뛰어난 ISA을 개발하는 것이 핵심인데, 이는 performace, implementation과 연관되어있다.
Quantitative Engineering Paradigm
Engineering은 가격 대비 성능이 좋은 유용한 제품을 만드는 것이다.
가격, 속도, 성능 등을 숫자(quantitative)로 표현하여 좋은 제품을 가린다.
Quantitative하게 표현하기 위해서 아래 3가지가 중요하다.
- What to measure?
- 좋은 컴퓨터란 무엇인가?
- 측정의 잣대 : 무엇을 가지고 비교할 것인지 알아야 한다.
- performance measures
- How to measure?
- 어떻게 측정할 것인가?
- evaluation methods
- How to improve?
- 어떻게 더 개선할 것인가?
- 어떤 요인들에 의해서 결정되는가는 컴퓨터에 대한 더 깊은 지식(domain knowledge)이 요구된다.
- performance models, domain knowledge
Power of Single Number
무언가를 비교하기 위해서는 숫자들이 너무 많기 때문에 비교하기 쉽지 않다.
따라서 single number로 표현하여 비교한다.
Computer science에서는 평균치로 표현하여 성능을 비교한다.
컴퓨터 Performance 비교 기준
컴퓨터의 성능을 비교하는 기준은 대표적으로 2가지가 있다.
- Response time
- 일을 처리하는데 시간이 얼마나 걸리는가?
- Throughput
- 주어진 시간 내에 얼마나 많은 일을 하는가?
범용 컴퓨터에서는 response time을 성능의 척도로 사용하기 때문에 parallel programming을 통해서 response time을 줄여야 한다.
Response time을 척도로 사용하는 이유?
컴퓨터의 성능을 비교하는데 있어서 주로 response time을 많이 이용한다.
1. response time을 개선시키면 throughput도 개선되지만, throughput을 개선하더라도 response time은 개선되지 않는다.
일을 처리하는 시간이 줄어들면, 주어진 내에 할 수 있는 일이 늘어난다.
즉, Response time이 좋아지면 자동으로 thorughput이 좋아진다.
만약 프로세서를 2배 빠른 프로세서로 교체한다면 response time은 2배 빨라질 것이다. 그에 따라 throughput도 2배 증가할 것이다.
그러나 만약 더 많은 프로세서를 추가한다면 response time은 그대로고 throughtput만 2배 증가할 것이다.
대부분의 프로세스는 단일 프로세서에서 동작하도록 설계되어있기 때문에 프로세서를 추가해도 response time은 그대로이기 때문이다.
2. throughput 측정의 어려움
또한 throughput을 측정하려면 대규모 테스트를 해야하는데 매번 대규모 테스트를 하기 힘들다.
참고 : Understanding Performance
- 알고리즘, 소프트웨어 구조
- 실행되는 operation의 수를 결정한다.
- 프로그래밍 언어, 컴파일러, Architecture
- operation 당 실행되는 machine instruction을 결정한다.
- 프로세서, 메모리 시스템
- instruction이 실행되는 속도를 결정한다.
- I/O 시스템, OS
- I/O operation이 실행되는 속도를 결정한다.
Multiprocessor System
멀티프로세서를 이용해서 성능을 개선하는 방식은 Parallel programming과 Natural parallelism 방식이 있다.
두 방식은 서로 대조된다. (Parallel programming ↔ Natural parallelism)
Parallel programming
Response time을 줄이는 방식이다.
문제가 복잡해서 푸는데 많은 시간이 소요될 때 유용하다.
Multiple processor을 이용해서 single large problem의 response time을 줄인다.
즉, 일을 나눠서 처리해서 빠르게 수행한다.
Supercomputer와 같이 과학 문제를 해결하는데 주로 사용된다.
Natural parallelism
Throughput을 줄이는 방식이다.
여러 프로세서에서 각각의 일을 처리하고, 각 일은 독립적이다.
데이터 센터와 같이 business computing을 해결하는데 주로 사용된다.
What to measure : Response Time
UNIX utility의 time의 결과가 다음과 같다고 하자.
결과가 나타내는 각 값은 다음과 같다.
<pre>time a.out : 90.7s 12.9s 2:39 65%</pre>
- 90.7s : User mode에서 동작한 시간
- 12.9s : Kernel mode에서 동작한 시간(user program이 system call 호출하는 등)
- 2:39 : 프로그램이 동작한 시간(시작 ~ 종료)
- 65% : 실제 CPU가 일한 시간(CPU time)의 비율
- (90.7s + 12.9s) / 2:39
Response Time
Response time은 다음과 같이 구분된다.
- Elapsed time = CPU time + I/O time
- 전체 시간으로, system performance을 결정한다.
- 프로그램이 시작해서 종료할 때까지의 시간(total response time)
- Processing, I/O, OS overhead, idle time 등이 모두 포함된다.
- CPU time = User CPU time + System CPU time
- = Elapsed time - I/O time
- CPU가 주어진 일을 처리하기 위해 동작한 시간
- 전체시간에서 I/O 등 공유하는데 사용된 시간이 제외된 시간
- User CPU time과 System CPU time으로 구분된다.
- user CPU time : user mode에서 동작한 시간
- system CPU time : kernel mode에서 동작한 시간
- I/O time
How to measure : Benchmarking
컴퓨터 성능은 프로그램의 response time을 이용해서 측정한다.
대상 프로그램은 실제 프로그램들을 대표할 수 있는 프로그램들을 이용한다.
이 프로그램들을 Benchmark, 이를 이용해서 측정하는 것을 Benchmarking이라 한다.
- Benchmarks
- collection of programs
- representative set of real programs
- Benchmarking
- benchmark을 이용해서 response time을 측정하는 것
Benchmarking
제 3자가 결과를 재생산할 수 있도록 configurartion, measurement condition 등 모든 조건을 공개해야 한다.
또한 가격 대비 성능(가성비)를 따질 수 있도록 비용을 공개해야 한다.
벤치마킹은 reference machine에 대한 상대적인 성능을 single number로 표현한다.
Reference machine은 시장에서 흔하게 구할 수 있는 컴퓨터를 기준으로 삼은 것이다.
컴퓨터 회사에서 성능이 좋지 않았을 때 조작하는 일이 발생하기도 한다.
그러나 모든 조건을 공개하기 때문에 조작하더라도 발각되기 쉽다.
실제로 1996년에 인텔에서 조작을 하였다가 발각되기도 하였다.
SPEC
System Performance Evaluation Corporation
CPU, web server, power consumption 등 다양한 분야의 벤치마크가 존재한다.
CPU benchmark는 프로세서 성능을 측정하기 위한 벤치마크로, computation-intensive workloads을 측정한다.
89, 92, 95, 2000, 2006, 2017에 CPU 벤치마크가 공개되었다.
초기에는 프로세서의 성능이 급성장하였기 때문에 새로운 벤치마크가 자주 등장하였지만, 이후 프로세서의 발전 속도가 느려졌기에 새로운 벤치마크 출시 속도도 느려졌다.
프로세서에는 Integer ALU와 FP ALU가 존재하기 때문에 integer benchmark와 floating-point benchmark로 나눠서 정의할 필요가 있다.
각 벤치마크들에 대해서 실제 머신에서 수행했을 때 response time이 reference machine에서 수행했을 때 response time보다 몇배 빠른지를 비교한다.
이후 이 값들을 평균으로 내어 single number로 표현한다.
다양한 벤치마크
TPC
TPC(Transactoin Processing Performance Council)에서 만든 벤치마크도 유명하다.
Business server에서 throughput의 성능을 측정하는데 사용된다.
- TPC-C
- order-entry transactions against database
- 아마존과 같이 온라인 물건 판매업을 하는 서버가 대상이다.
- TPC-E
- brokerage firm
- 증권거래 등 중개 서버가 대상이다.
- TPC-H
- decision support system, data mining
- 미래 경영전략을 산출하는 서버가 대상이다.
Embedded System
EEMBC는 대표적인 embedded benchmark suites로, autonomous driving, mobile imaging, internet of things 등의 임베디드 시스템에서 사용될 수 있다.
임베디드 시스템은 종류가 매우 많아서 모든 임베디드 시스템에 대한 벤치마크를 설계할 수는 없다.
때문에 없는 경우에는 제 3자가 보더라도 적절성이 있는 벤치마크를 스스로 개발해서 사용해한다.
PC benchmark
일반 사용자들은 PC 벤치마크를 사용하지 않고, 주로 PC 제조회사에서 PC 벤치마크를 사용한다.
대신 일반 사용자들은 clock cycle, memory size, disk capacity, display 등을 이용해서 성능을 비교한다.
| Business Winstone | Run a script that simulates a user switching among and running different applications |
| CC Winstone | Simulate multiple applications focused on content creation, such as Photoshop and audio-editing programs |
| Winbench | Run multiple scripts that test the performance of CPU, video system and disk |
SPEC Power Benchmark
Mobile device나 Large-scale data center에서는 power comsumption을 줄이는 것이 중요하다.
SPECpower_ssj2008 for X4는 power consumtion에 대한 벤치마크이다.
'Computer Science > Computer Architecture' 카테고리의 다른 글
| 1. Good ISA (0) | 2021.04.10 |
|---|---|
| 1. 컴퓨터 성능 개선/결정 (How to improve) (0) | 2021.04.03 |
| 성능을 위한 ISA 구현 방법(간략) (0) | 2021.03.27 |
| I/O : Interrupt (+ Atomic) (0) | 2021.03.27 |
| I/O : Interconnection (0) | 2021.03.27 |
댓글