[Computer_Architecture] Performance Part.2

# of Instructions Example

한 컴파일러 설계자가 특정 컴퓨터에 대한 두 개의 코드 시퀀스 사이에서 결정하려고 합니다.

• 여기서 성능 상향을 위한 질문들이 있습니다.
  • 여기서 CPI (명령어당 Clock Cycle)의 값은 변경되지 않습니다.
• 어떤 순서가 빠를까요? 얼마인가요?
• 각 시퀀스에 대한 CPI는 얼마인가요?
• 그 아래에 대한 질문의 결과는 아래에 있습니다.

정리를 못해서 죄송합니다...

여기서 우리가 알아야 할거는 성능 평가에서 착각을 할수도 있으니 조심을 해야 한다는 것입니다.

---

Understanding Program Performance

여기서 우리가 알아야 하는건 CPI에 대한 착각을 하지 말아야 하는 것입니다.
Affects what: CPI → 안바뀌는 CPI랑 다른것입니다.

---

Amdahl’s Law (암달의 법칙) = 무어의 법칙

암달의 법칙 → 가장 common한것을 빠르게 만드는 것입니다. 이점은 전체 성능에 큰 영향을 미칩니다.

• 무어의 법칙: 18 Array(배열)마다 반도체 IC칩 마다 들어가는 트랜지스터의 양이 x2 (많으면 성능 향상이 이루어집니다.)
• 암달의 법칙: 똑같은 일(힘 & 노력) 투자시, 주로 발생(Common)한거에 투자합니다.
• Execution Time After Improvement (수행시간 관점에서 성능 향상률?)

Example

한번 예제를 한번 보겠습니다.

• “Multiply(곱셈)”이 전체 100초 중 80초를 차지할 때, Multiply 성능을 얼마나 개선해야 전체 성능이 5배 향상될까요?
• 전체 실행 시간 = 100초
• 곱셈 연산이 차지하는 시간 = 80초
• 목표 성능 향상 배수 = 5배
• 전체 실행 시간을 5배 빠르게 만들기 위해 필요한 곱셈 연산의 성능 향상을 구해보겠습니다.
  • 개선 후의 전체 실행 시간은 20초입니다.

---

Benchmark → 성능 측정 & 평가

• 실제 애플리케이션을 실행하여 최적의 성능을 결정합니다.
  • 실제 환경에서 모의 평가: 성능 평가 용도로 사용합니다.
  • 예상되는 부하량의 전형적인 프로그램을 사용합니다.
  • 또는 예상되는 애플리케이션 클래스의 일반적인 유형으로 구성됩니다.
  • 그리고 공정한 평가를 위해 복잡한 벤치마크를 사용합니다.
• 예를 들어 컴파일러/편집기, 과학 애플리케이션, 그래픽 등입니다.
  • 벤치마크 속도를 높이는 방법 찾기가 어렵습니다(즉, 분석이 너무 어렵습니다)
  • 역으로 벤치마크를 분석하기 어렵게 한다. (악용 방지 목적)
• Small Benchmarks → 구현 단계에서 신속한 평가를 위해 사용합니다.
  • Architects 및 Designer (특히 초기 단계)에게 적합합니다.
  • 표준화가 용이함
  • 구현이 용이함
  • 단, 남용될 수 있습니다. (어뷰징 가능)

Report: Reproducibility → 재생성이 가능한? (검증이 잘되는?)

재생산(다른 컴퓨터에서도 같은 결과 보장)이 가능해야 합니다

Performance Summary

• 여기서 우리가 알아야 할것이 있습니다.
• Single Number(단일 숫자)로 특성을 지정하는 방법은 무엇인가요? 2가지가 있습니다.

• Arithmetic Mean은 평균 반영이 어렵다는 점이 있습니다. 
• 그리고 Weight AM은 각 프로그램의 중요도(Weigjt-가중치)를 준 값을 합쳐서 비교 한다는 특징이 있습니다.

---

Normalized Performance (성능 정규화)

표준화된 실행 시간은 성능 확정에 유용하다는 특징이 있습니다.

• 총 실행 시간을 계산해보면 A는 B보다 (101/60) = 1.7(P1과 P2의 실행 횟수가 같음) 만큼 빠릅니다
• 이때 상대시간 AM은 → 무엇을 기준으로 하냐애 따라 성능이 오락가락(즉, 모호해짐) 한다는 특징이 있습니다. (성능 정규화의 단점)
  • A는 B보다 5배 빠릅니다 / B는 A보다 25배 빠릅니다
• 이때 AM과의 상대적인 실행 시간을 요약하지 말아야 합니다. → 그러면 뭘 써야 하나요? 이땐 Geometric Mean (기하평균)을 써야합니다.

---

Geometric Mean (기하 평균)

기하 평균은 상대 측도를 요약하는 데 사용됩니다.

• 표를 보면 우리가 알 수 있는 사실이 있습니다.
  • A에 비해 B가 2.2배 빠릅니다
  • B에 비해 A가 2.2배 빠릅니다.
  • 근데, 이러면 산술평균으로 계산한 의미가 없습니다, 값이 같기 때문입니다. 이럴땐 기하평균으로 계산 해야합니다.
• 그러나, 불행한 두 가지 속성 → 기하평균에서 두가지의 단점이 존재합니다.
  • 단점1: 실행 시간을 추적하지 않습니다 → 수행시간을 잘 반영하지 않습니다.
  • 단점 2: 모든 개선 사항에 대해 동등하게 보상합니다 → 모든성능의 Contribution값(기여, 영향력값)이 다 같아집니다..
    • 기계 B에서 P1에서 50초 기여 = P2에서 0.5초 기여 → 영향력이 같아진다는 특징이 있습니다.

---

SPEC (System Performance Evaluation Cooperative)

• 1988년에 5개 회사가 실제 프로그램 및 입력(Apollo, HP, DEC, MIPS, Sun)에 합의했습니다
• SPEC89: VAX-11/780으로 정규화 → 각 연도별로 대중적인 Server로 벤치마크 결과값을 도출합니다.
• SPEC2000: Sun Ultra5_10 300MHz로 정규화합니다.
• SPEC2006
  • 선택한 프로그램을 실행하기 위한 경과 시간(Pocus on CPU Perf)
  • 성능 비율의 기하학적 평균으로 요약됩니다.
  • 12개의 정수 벤치마크(CINT2006)
  • 17개 부동 소수점 벤치마크(CFP2006)\

 

SPEC2017 Integer Benchmark (on 1.8GHz Intel Xeon E5-2560L)

---

Power is also an important metric

성능이 올라가면서 power도 성능의 중요한 지표중 하나로 사용되고 있습니다.

• Power = 𝐶𝑎𝑝𝑎𝑐𝑖𝑡𝑖𝑣𝑒 𝑙𝑜𝑎𝑑 × 𝑉𝑜𝑙𝑡𝑎𝑔𝑒 ** 2 (전압의 제곱) × 𝐹𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑦 𝑠𝑤𝑖𝑡𝑐h𝑒𝑑
  • Power(전력)이 상승하면, 다 올라간다는 특징이 있습니다.

• 시계는 1000배 증가한 반면 전력은 30배 증가했습니다
  • 1세대당 약 15% 전압 감소(5V → 1V)

---

Reducing Power

만약 CPU에 다음과 같은 기능이 있다고 가정합니다.

• 기존 CPU 용량 부하의 85%
  • 전압 15%, frequency 15% 감소

• 그리고 Power Wall 이라는 개념이 있습니다. 주요 특징은 더 이상 전압을 낮출 수 없는것, 더 많은 열을 제거할 수 없는것 입니다.
• 그 외에 어떻게 하면 성능을 향상시킬 수 있을까요?

---

Multiprocessors

• 멀티코어 마이크로프로세서
  • 칩당 하나 이상의 프로세서가 있습니다.
• 명시적으로 병렬 프로그래밍이 필요합니다 - Parallel Programming
  • 명령 수준 병렬과 비교
    • 하드웨어가 여러 명령어를 한 번에 실행합니다
    • 프로그래머로부터 숨깁니다.
  • 하기힘든일은 아래에 명시되어 있습니다.
    • 1. 성능을 위한 프로그래밍
    • 2. 로드 밸런싱
    • 3. 통신 및 동기화 최적화

---

SPEC Power Benchmark

• 다양한 워크로드 수준에서 서버의 전력 소비량을 나타내는 지표입니다.
  • 성능 : ssj_ops / sec (서버측 java operations / sec)
  • 전력: 와트(줄/초)

Fallacy: Low Power at Idle

• i7 파워 벤치마크를 돌아봅니다
  • 100% 부하 시: 258W
  • 50% 부하 시: 170W(66%)
  • 10% 부하 시: 121W(47%)
• 구글 데이터 센터
  • 대부분 10% - 50% 부하에서 작동
  • 100% 부하 시 전체 시간의 1% 미만
• 부하에 비례하는 전력이 되도록 프로세서를 설계하는 것을 고려합니다.

 

Summary.

• 성능은 특정 프로그램에 따라 다릅니다
  • 총 실행 시간은 일관된 성능 요약입니다
• 주어진 아키텍처의 성능 향상은 다음과 같습니다:
  • 클럭 속도 증가(CPI에 악영향을 미치지 않음)
  • CPI를 낮추는 프로세서 조직 개선
  • CPI 및/또는 명령어 수를 낮추는 컴파일러 향상 기능
• Pitfall – 기계 성능의 한 측면의 개선이 전체 성능에 영향을 미칠 것으로 예상됩니다 (Performance, Energy?)