회사나 경력의 흥망성쇠를 쥐고 있는 힘은 무엇인가? 논쟁의 열기와 격한 감정, 그리고 격렬한 시비를 불러일으키는 힘은 무엇인가? 섹스 스캔들? 소송? 아니다. ? 벤치마크를 보라. 수백만 달러의 수퍼컴퓨터와 엄청난 정부의 계약 시절부터 벤치마크(Benchmark)는 생산제품과 이 생산제품에 관여한 사람들의 흥망성쇠를 좌우하는데 중요한 부분을 차지해왔다. 수퍼컴퓨터 전쟁이 수많은 제품들이 나오면서 냉전으로 치닫고 나서 대신 현대 플랫폼 전쟁으로 이어지게 된다. 윈텔(인텔+윈도우), 맥, Irix, Alpah(linux와 NT)같이 플랫폼을 대변하는 것들(하드웨어 + 운영체제)은 종교적인 열정으로 어느 운영체제가 우월한지 보여주는 벤치마크를 보여주며 뉴스그룹과 웹페이지에서 격렬하게 싸워왔다. 우리의 대부분이 알고 있는 것처럼 대부분의 일들은 지나쳐가기 마련이다. 벤치마크는 설계자들이 설계 결정을 내리는데 도움을 주고, 소비자들이 알고 나서 구매결정을 하는데 도움을 준다. 한 사용자의 플렛폼이 절대적이고 월등하다는 것을 증명하기 위해 벤치마크를 사용하는 것은 많은 적들을 이기는데 별 도움이 되지 못한다.
플랫폼 열광자들만이 벤치마크를 사용하고 악용하는 사람들만 아니라, 벤치마크에 많은 투자를 한 업체들도 또한 그렇기도 하다. 업체의 설계 팀에 의해서 벤치마크는 성능 병목과 낭비되는 작업 부분을 찾고 제거하는데 꼭 필요한 도구이다. 업체의 마케팅 부분에서는 벤치마크는 완전히 다른 부분에서 사용된다. 업체가 제공하는 벤치마크를 평가할 경우, 소비자는 이러한 최고의 성능부분을 믿으려는 경향을 보이게 된다. 이러한 벤치마크로 업체는 이익과 명성을 남길 수 있다. 결과로, 이러한 업체들은 벤치마크 트위킹(벤치마크를 변형)을 고차원적의 예술로 끌어올린 결과를 가져오게 되었다.
아마도 가장 논쟁의 거리가 되는, 가장 악용되는 그리고 가장 잘 이해되지 못하는 벤치마킹의 부분은 CPU 벤치마크 일 것이다. CPU 벤치마크는 각각 다른 모양과 크기로 주어지지만 SPEC CPU 벤치마크 류는 이 중 가장 유명한 것이다.사람들은 SPEC 벤치마크 결과를 성스러운 문서처럼 여긴다. 다른 벤치마크 류는 잘 알려져 있긴 하지만, 업체가 자사의 CPU를 내놓으려면 인상적인 SPEC CPU 결과는 매우 중요한 인자이다. 그렇다면 SPEC, 그리고 이와 비슷한 다른 CPU 벤치마크는 성능을 정말 잘 반영하는 것일까? 자주 인용되는GFLOPS와 MIPS는 어떠한가? 이 수치들이 알려주는 바는 얼마나 될까?
이 글에서 본인은 SPEC92와 SPEC95 CPU벤치마크가 어떻게 작동하는가를 보여 줌으로서 이러한 질문들에 답변할 것이다. 이것의 잇점과 불이익에 관해서 이야기 할 것이며, 업체들이 이 수치를 끌어올리기 위해 어떠한 방법으로 편법을 사용하는지 이야기 할 것이다. 그러나 무엇보다도 가장 먼저, MIPS와 GFLOPS 그리고 다른 몇 개의 일반적으로 사용되는 성능의 잣대에 대해서 이야기 하겠다. 마지막에 몇 개의 결론과 PC 매니어들을 위한 조언을 하려 한다.
노트 : CPU성능을 논 할때에는 첫 시작으로는 Hennesy와 Petterson의 컴퓨터 구조에 대한 연구 결과인 Computer Architecture;정량적 접근 을 보는 것이 좋다. 이 책은 대부분의 컴퓨터 구조 코스에서 표준적인 책이며, 글쓰기의 명확함과 다루는 범위의 깊이에 있어서는 최고 이다. 첫번째 챕터에서 Hennesy와 Patterson은 CPU성능을 판단하고 알리는데 필요한 기본적인 법칙과 개념을 설명한다. 이 책에는 본인은 그 어디에서도 아직 보지 못한 SPEC92에 대한 정보도 포함되어 잇다. 그러므로 여기서 논할 부분은 그들의 작업에 기초한 것이고, 적절한 다른 소스도 역시 포함시킬 것이다. 이 글에서 사용된 다른 정보의 대부분은 http://www.spec.org에서 가져온 것이다.
MIPS 와 GFLOPS
모든 성능의 측정 방법중 잘못된 것 중에서, MIPS와 GFLOPS는 가장 널리 퍼진 것들일 것이다. 본인 자신도 업체에서 제공한 GFLOP 수치를 인용하기도 했고, (이것 외에는 선택할 수 있는 방법이 없었지만), 당시에는 선택의 폭이 넓지가 않았다. 두개중에 MIPS (초당 백만개의 명령어)는 프로그램의 명령어를 셈한 것을 실행시간(밀리초단위)으로 나눈 값이다.
MIPS를 비판하기 위해서 그렇게 열심히 생각할 필요조차도 없다. 특정한 프로그램에 대해 명령어를 세는 것은 완전히 프로그램 자체의 성격과 명령어 셋 구조(ISA)에 달려 있는 것이다. 예로서 “Hello World” 프로그램의 경우, CISC ISA 시스템에서 컴파일 되면 열개 정도의 명령어를 사용할 것이지만 RISC ISA 시스템에서 컴파일 될 경우 20개를 사용할 수도 있다. 두종의 CPU간에서 이 프로그램을 실행시키는데 같은 시간이 걸렸다면, RISC칩이 CISC보다 2배 많은 MIPS 수치를 나타낼 것이다. 하지만 두개의 시스템이 같은 작업을 하는데 같은 시간이 걸리지 않았는가? 사실 MIPS가 ISA에만 따라 변화폭이 심한 것은 아니다. 같은 시스템에서 다른 프로그램간에도 격차가 있다.
MIPS가 성능을 측정하는 잣대로 나쁜 만큼, GFLOPS도 별로 나을 바 없다. GFLOPS(초당 10억개의 부동소수 연산)를 측정하려면, 프로그램에서 부동소수 연산 수를 밀리초단위의 실행시간으로 나누면 된다. 이러한 접근 방법의 문제는 프로그램에 따라서 부동소수 연산수가 변한다는 사실이다. 두개의 프로그램이 있다고 하자, 첫째는 80%가 부동소수 연산이고 둘째는 20%이고, 두개를 실행시키는데 같은 시간이 걸렸다면, 다른 GFLOPS 수치가 나올 것이다.
또한 GFLOPS의 더 큰 문제는 모든 기계에 같은 부동소수 명령어가 적용되지 않는다는 점이다. 한 개의 기계가 특정한 작업을 하기 위해 두개의 부동소수 연산을 하지만 다른기계에서는 같은 작업에 단 한 개의 연산만을 할 수도 있다. 만약 같은 시간내에 작업을 수행한다면, 두개의 연산을 한 기계가 높은 GFLOPS 수치를 나타낼 것이다.
간단히 말해서 GFLOPS나 MIPS는 믿을만한 벤치마크의 성능을 나타낼 수 없다는 것이다. 다음 번에 MIPS나 GFLOPS 수치를 보면, 출처가 어디인가 확인해 보라.. ? 본인은 99% 업체가 제공한 것이라고 보장한다. 이것에 대한 이유는 두가지이다. 첫째는 업체만이 프로그램에 명령어들을 세고 시간을 잴 유일한 사람들이고 MIPS와 GFLOPS를 측정하기 위해 모든 일들을 떠맡아 할 유일한 사람들이기 때문이다. 둘째로 업체들은 이러한 측정 수치로 이익을 얻는 사람들이기 때문이다. 대부분의 소비자들은 부동소수 연산능력을 가늠할 수 있는 업체의 구조와 이와 경쟁하는 다른 업체의 구조에 대해서 충분히 알고 있지 못하다. 만약 소비자가 이러한 사실을 안다고 해도, 업체들은 이 측정치에 어떠한 프로그램이 사용되었고 어떠한 명령어의 조합이 사용되었는지 누설하지 않는다 그러므로 아무런 소용이 없다.
다행하게도, 다른 방법이 분명히 있다.
실제 어플리케이션을 사용하는 것이다.
컴퓨터 성능을 측정할 때, 가장 중요한 부분은 매일 사용하는 프로그램들을 가능한 한 빨리 실행할 수 있냐는 것이다. 그러므로 가장 유명하고, 좋은 방법은 실제 사용하는 프로그램을 돌려보고 이 작업을 수행하는데 얼마나 오래 걸리는지 보는 것이다. 이러한 접근 방법은 전체 시스템을 벤치마킹하는데 탁월한 방법이다. (램, 디스크 시스템, 마더보드..등등)하지만 이것은 CPU에 대한 믿을만한 정보를 제공하지는 못한다. 퀘이크2를 실행시키고 timedemo를 돌리면 최후의 FPS는 메모리 레이턴시, 하드 디스크 성능, 비디오 카드성능과 많은 다른 요소들에 의해 결정된다. 또한 멀티테스킹 운영체제는 실행 하는 프로그램 이외에 많은 다른 요소들을 실행중이고, 이러한 프로세스들만이 CPU시간을 잡아먹는 것 뿐만 아니라 한 프로그램에서 다른 프로그램으로 진행하는 데에도 역시 시간이 소요된다.(레지스터 내용과 스택 포인터, 등등을 저장해야 하기 때문이다.)
“프로그램이 실제로 얻어내는 CPU점유시간” 대 “입/출력을 기다리는데 사용되는 시간”은 프로그램마다 다르다. 프로그램에 사용된 실제 CPU 시간은 User time이라 불린다. 운영체제나 다른 프로그램에 사용된 CPU시간은 system time이라 불린다. 그렇다면 과연 사용자는 장치 드라이버와 입출력 서브시스템, 혹은 CPU중에 무엇을 벤치마크했나 자문할 필요가 있다. 이상적으로 user time을 최대한 많이 사용하는 벤치마크를 돌리는 것이 가장 좋을 것이다.
결론은 이렇다. CPU에 의존적인 프로그램을 돌리고 스톱워치로 시간을 재는 것은 완전한 플랫폼의 성능을 알아는데는 좋은 방법이지만 이것은 CPU성능에 대해서 구체적으로 알려주지는 못한다. 어플리케이션 성능은 두개의 다른 플랫폼을 비교할 때에 실행시에는 더욱 CPU 벤치마크에서 현실적이지 못하게 된다. 어플리케이션이 한 개의 플렛폼에서 최대의 성능을 내도록 조정되어 있을 수도 있고 다른 플랫폼에서는 그저 실행만 되게 포팅되었을 지도 모르는 일이다. 그러므로 맥에서 포토샵을 실행하고 PC에서 실행하는 것은 G3가 PII보다 우수하다는 것을 말해줄 수 없는 것이다. 이것이 이야기해주는 것은 PC에서보다 맥에서 포토샵이 잘 돌아간다는것만을 이야기 해주는 것이다. 포토샵은 이 경우 탁월한 예이다. Caesar는 최근에 G3에서의 벤치마크를 다른 인텔 프로세서에서 실행했을 때 와 비교해서 벤치마크를 하고 있다. 첫번째 몇번의 테스트 후에, 그는 메모리, 운영체제 구조와 기타 많은 이유로 인한 문제로 옴싹달싹 못하고 있다.
위에 논의에 대해서 생각해 보면, 실제 어플리케이션이 CPU성능을 측정하는 데에는 그리 좋은 방법이 아닌 것 처럼 들린다. 만약 관심있는 부분이 CPU 성능에 대해서라면 실제 어플리케이션 벤치마크는 최선의 방법은 아니다. 그러나 시스템 전체로서의 벤치마크에 관심이 있다면 (이것만이 벤치마크를 하는 진정한 이유이지만), 실제 어플리케이션을 돌려보는 것은 최고의 방법이다.
벤치마크 프로그램의 문제점
실제 어플리케이션들이 플랫폼의 특별한 부분에 대해서 알려주지 못하므로, 대안으로는 CPU성능을 벤치마킹하기 위해서 설계된 프로그램을 사용하는 것이다. 이런 프로그램들이 많이 있고, 모두 다른 방법을 채택하고 있다. Hennesy와 Patterson은 벤치마크 프로그램들을 세가지로 분류를 하고 있다. (실제 어플리케이션이 아닌)
첫번째 프로그램은 커널이라 불리는 것이다. 커널은 독립적으로 실행되거나 아니면 벤치마크 프로그램의 부분으로 실행되는 작은 CPU에 집중적인 실제 프로그램이다.이 커널의 아이디어는 모든 입/출력 요구와 다른 시스템의 호출을 제외시켜버리면 프로그램이 얻는 user time을 최대화 할 수 있다는 것이다. 설계 상태에서 커널은 기계의 특정한 부분의 성능을 끌어올리고 설계의 비효율적인 부분을 낮추는데 아주 유용한 도구가 될 수 있다. 문제는 업체가 이것을 마케팅의 목적으로 사용할 때 나타난다.
커널이 표준 벤치마크 프로그램의 부분으로 사용될 경우 ? 그리고 SPEC는 많은 커널을 포함하고 있다. ? 이것들은 컴파일러 최적화의 목표가 된다. 컴파일러 작성자들은 몇 개의 특정한 커널에 대해서 집중적으로 최적화를 시킬 수 있고 전체 벤치마크 성능을 막대히 끌어올릴 수 있다. Hennessy 와 Patterson은 몇몇 시스템에서 컴파일러 최적화는 SPEC 의 nasa7 커널을 2.1배로 끌어올릴 수 있다고 밝혔다. 이러한 일이 발생할 경우, 하드웨어를 벤치마크하는 것이 아니라, 컴파일러를 벤치마크하는 결과가 된다. 많은 컴파일러들은 실제에는 전혀 사용되지 않는 특정한 벤치마크에 적절한 최적화 사양을 포함하고 있으며, 이것의 유일한 목표는 특정한 벤치마크에서 성능 향상을 보여주기 위한 것이다.
실제로 현재 CPU들이 컴파일러 기술에 의존적임을 고려해 볼 경우, “컴파일러를 벤치마크”한다고 해도 그리 틀린 말은 아니다. 인텔의 차세대 아키텍쳐인 IA-64의 경우, 컴파일러와 하드웨어 사이의 경계선이 의도적으로 흐려져 있다. 그러므로 컴파일러 최적화가 실제 어플리케이션에서 성능향상을 보인다면 컴파일러 최적화는 실제로 “속이는”짓을 하는 것은 아니다. 사실, SPEC95는 CPU, 메모리 구조 그리고 컴파일러를 벤치마크 한다고 주장한다. 이 세개의 부분들은 매우 상호 의존적이여서 각각 각개로 벤치마크를 하는 것은 불가능하다.
벤치마크 프로그램의 두번째 종류는 Hennessy와 Patterson이 정의한 바에 의하면 장난감 벤치마크라 불리는 것이다. 장난감 벤치마크는 Quicksort이나 Sieve OF Eratosthenes같은 사람들이 어떠한 컴퓨터에서도 컴파일할 수 있는 작은 프로그램들이다. 이러한 벤치마크는 실제로 측정하는 것은 별로 없다. 그리고 저자의 의견에 의하면 “이러한 프로그램들의 가장 좋은 용도는 프로그래밍을 시작하는사람들에게 주는 숙제로 사용하는 것”이라고 한다.
세번째 종류는 통합적인 벤치마크이다. Dhrystone이나 Whetstone같은 종합적인 벤치마크는 일반적인 프로그램의 평균적인 명령어의 조합을 사용해서 CPU에서 이러한 명령어들을 조합하고 실행하는 것을 복제하게 해서 보는 것이다. 통합적인 벤치마크는, 정의에 의하면 실제 프로그램은 아니고 이것들의 코드는 그 누구도 계산하기를 원하는 결과를 계산하지 않는다. 그래서 결과는 실제 프로그램에서의 성능을 예측하는데 쓸모없을 수도 있고 유용할 수도 있다. 통합적인 벤치프로그램의 문제는 매우 많고, 이것 자체가 한 개의 글의 주제가 될 수 있을 정도이다. Hennesy와 Patterson은 이러한 벤치마크들은 열거한 벤치마크 종류중 가장 쓸모없는 것이라고 피력해 놓았다.
통합적 벤치마크 비난하기.
실제로, 본인은 통합적 벤치마크에 대한 비판에 대해서 논할 예정인데, 이 섹션에서 내가 피력하는 내용들이 이것은 이렇게 함으로써 모든 벤치마크 프로그램에 적용시킬 수 있기 때문이다. 비판 내용은 다음과 같다. 벤치마크 어플리케이션의 유일한 목적은 벤치마크 결과를 얻기 위함인데, 이 결과들이 , 정의에 의하면, 실제 세계에서 얻을 수 있는 결과는 아니라는것이다. 이것이 뜻하는 바는 무엇인가? 유명한 통합 벤치마크 프로그램들을 예로 보자. WinBench를 보면 대략적인 성능을 예측하기 위한 빠르고 지저분한 비교결과를 얻을 수 잇다. 그러나 윈벤치의 CPUMark 99점수가 과면 사용자가 원하는 것인가 스스로 자문해볼 필요가 있다. 직면해보자, 모든 윈벤치 CPUMark99가 말해주는 것은 사용자의 시스템이 CPUMark99에서 얼마나 잘 실행된다는 것을 이야기 해 줄 뿐이다. ? 이것은 사용자의 시스템이 실제로 사용자가 쓰는 어플리케이션이 어떻게 돌아갈지 알려 줄 수도 있고 전혀 아닐 수도 있는 것이다. CPUMark에서 스프레드 시트를 계산하는가? 문서작성은 어떤가? 윈벤치 클랜의 멤버인가? 위의 질문에 대한 대답이 전부 “아니오”라면, 윈벤치 CPUMark99점수는 생각했던 것 처럼 Ziff Davis만큼 중요하지 않을 수도 있는 것이다.
SPEC 의 문제는
종종 , 단 한 개의 벤치마킹 프로그램을 사용함으로 인한 그 프로그램 고유의 문제를 여러 많은 벤치마크를 사용함으로서 시스템의 다른 부분들에 대한 것에 대해서 해결을 할 수가 있다. 이것이 벤치마크 프로그램의 기본적인 생각이다. CPU 성능을 측정하는데 가장 유명한 벤치마크 프로그램은 SPEC이다. SPEC 웹사이트에 의하면 :
기본적인 SPEC의 방법은 벤치마킹(Benchmarking)하는 사람들에게 실존하는 많은 넓은 범위의 플랫폼에 이식된 어플리케이션에 기초한 표준화된 소스코드를 제공한다는것이다. 벤치마커는 이 소스코드를 가지고 테스트하려는 시스템에서 컴파일(compile)하고 최적의 결과를 얻기 위해 시스템을 튜닝할 수 있다. 이미 인정되었고, 이식된 코드의 사용은 사과 대 오렌지 식의 비교를 하는 것에 대한 문제를 줄였다.
SPEC은 부동소수 집중적인 것들과 정수 연산 집중적인 커널과 프로그램들도 이루어져 있다. 업체들은 프로그램의 소스를 가지고 스스로 벤치마크전에 컴파일을 한다. 업체는 두개의 성적을 제출해야만 한다. 기본적 성능의 측정과 최적화후의 성능 측정결과이다. 기본적 성능 측정은 업체가 단일 세트의 플래그와 단일 컴파일러를 같은 언어에서 모든 벤치마크에 사용해야 한다. SPEC92는 업체들이 스스로 제작한 컴파일러를 도저히 이해가 불가능한 난해한 옵션을 사용하여 기초성능 성적을 얻는 것을 인정하고 있다. 이러한 컴파일러 만들기는 기본적 성능에 막대한 영향을 미쳤다. SPEC95는 벤치마크 프로그램을 실행하고 빌드하는데 필요한 도구들을 명시하고 있으며 이식성 플래그를 제외한 컴파일러 플래그의 숫자를 넷으로 제한하고 있다.
SPEC92에서는 최적화된 성능측정은 업체들로 하여금 벤치마크에 특정적인.그래서 일반적인 프로그램에서는 불합리한 코드를 생성하거나 무척 느린 코드를 만들어낼 컴파일러 플래그를 사용하게 허용하고 있다. 몇몇 경우에는, 최적화된 성적과 비 최적화된 성능 점수간의 차이가 엄청나게 나기도 한다. SPEC95가 발표됨으로서, 업체들을 통제하려는 몇몇 노력이 현실화 되었다. SPEC은 안전하지 않은 코드를 일반적으로 생성해낼 플레그나 일반적 어플리케이션에서 업체가 전혀 사용하지 않을 코드를 사용하는 것을 막기위해서 제정된 몇 개의 규칙을 더하였다. SPEC은 현재 컴파일러 최적화의 사용에 대해서 다음과 같은 규정을 추진하고 있다.
CINT95/CFP95 벤치마크를 실행하는데 사용되는 하드웨어와 소프트웨어는 일반적인 C나 포트란 프로그램을 실행할 수 있는 적절한 환경을 제공해야만 한다.
최적화는 프로그램의 클래스에 알맞은 올바른 코드를 생성해야만하고, 프로그램의 클래스는 단일 SPEC 벤치마크나 SPEC 벤치마크 스위트보다 커야 한다. 이것은 Non-base/”집중적 컴파일”(섹션 2.2.4 p2참조) 측정에 사용되는 “선언 플래그”에도 또한 해당된다.
최적화는 한 개의 SPEC벤치마크나 SPEC 벤치마크 스위트보다 프로그램의 클래스가 커야하고, 최적화는 프로그램의 클래스의 성능을 향상시키는데에 중점을 두어야 한다.
-. 업체는 일반적인 사용으로의 응용을 촉진해야 한다.
-. 업체가 응용하는 것은 일반적으로 가능하고, 문서화와 지원은 업체에 의해 제공된다.
성능을 결론짓기 위해, SPEC 는 SPEC을 이루는 프로그램들의 표준화된 실행시간의 기하학적 평균을 사용한다. 이것의 의미하는 바는, 첫번째로 각 프로그램의 실행시간이 기준 기계에서 같은 프로그램의 기초 실행시간으로 표준화된다는것이다. SPEC92에는, 표준기계로 VAX-11/780이 선정되었다. SECC95에서는 기준기계로 SPARCstatioon 10/40(L2 캐쉬없는 40MHz SuperSPARC)이 선정되었다. 표준화 비율이 어떻게 사용되는가 알려주기 위해서, 다음 예를 들어보기로 하자. 기준 기계에서 GCC 테스트에 10초가 걸리고 벤치마크 하려는 기계에서 1초가 걸렸다고 하면 GCC는 벤치마크 기계에서 표준화 실행시간이 0.1초가 된다. N 표준화 실행시간은 같이 곱해져서 N 승의 근을 구하면, 이것이 실행시간의 표준화된 기하학적 평균이 되는 것이다.
이것이 의미하는 바는 무엇일까? 결국에는 특정한 프로그램이 실행하는데 몇초가 걸렸나가 중요한 것이 아니라, 기준기계에서 실행하는데 걸린시간보다 벤치마킹하는 기계에서 프로그램이 얼마나 빨리 더 실행되었냐 하는 것이다. 여기 GCC의 예에서는 벤치마킹하는 기계가 GCC 프로그램을 기준기계보다 10배 빨리 실행시켰다. 최종성적을 계산하기위해서는 기준기계보다 테스트하는 기계가 얼마나 빨리 각 프로그램을 실행시켰나 알아내고, 이 비율의 기하학적 평균을 취해야 한다. 이 부분에서 기하학적 평균을 설명하려는 것은 아니다. 다만 이것이 비율의 대수적 평균을 구하는 것보다 훨씬 좋은 방법임을 알아두기 바란다.
성능의 결론적인 잣대로 기하학적 평균을 사용하는 데에는 아직 찬반 양론이 많다. 기하학적 평균을 사용하는 데의 찬성 의견은 개개 프로그램의 실제 실행 시간에 대해 독립적이라는 사실이다. ?기억하는가, 모든 실행시간은 표준화 된다. 또한 모든 벤치마크 성적이 상대적이므로 어떠한 기계가 기준기계로 사용되는가 상관이 없다. 표준화된 기하학적 평균을 사용하는데 약점은 업체들이 크랙하기 쉬운 프로그램들의 성적을 향상시키는데에만 집중한다는데에 있다. 만약 프로그램이 2초에 실행된다면, 설계의 몇 부분을 최적화(컴파일러나 하드웨어)를 한 이후에 업체는 이 프로그램을 1초에 실행가능하게 한다. 이것은 마치 1000초 걸리는 프로그램이 500초 걸리는 것처럼 보이게 해서 전체 성적의 증가를 얻게하는 결과를 낳게 될 것이다.그러므로 만약 성능 향상의 비율이 같다면 비현실적인 성능향상이 마치 실제 성능의 향상처럼 보여지게 된다.
실제 벤치마크 실행의 SPEC95 결과 보고서는 많은 수치와 그래프로 구성되어 있다.SPEC95의 Q&A에서 발췌해낸 가장 중요한 8가지 수치가 아래에 있다.
CINT95:
SPECint95: 각각의 벤치마크에 집중적으로 최적화하여 컴파일한 8개의 표준화된 비율(각각의 정수 벤치마크)의 기하학적 평균치
SPECint_base95: 각각의 벤치마크에 일반적으로 최적화하여 컴파일한 8개의 표준화된 비율(각각의 정수 벤치마크)의 기하학적 평균치
SPECint_rate95: 각각의 벤치마크에 집중적으로 최적화하여 컴파일한 8개의 표준화된 처리량의 비율(각각의 정수 벤치마크)의 기하학적 평균치
SPECint_rate_base95: 각각의 벤치마크에 일반적으로 최적화하여 컴파일한 8개의 표준화된 처리량의 비율(각각의 정수 벤치마크)의 기하학적 평균치
CFP95:
SPECfp95: 각각의 벤치마크에 집중적으로 최적화하여 컴파일한 10개의 표준화된 비율(각각의 부동소수 벤치마크)의 기하학적 평균치
SPECfp_base95: 각각의 벤치마크에 일반적으로 최적화하여 컴파일한 10개의 표준화된 비율(각각의 부동소수 벤치마크)의 기하학적 평균치
SPECfp_rate95: 각각의 벤치마크에 집중적으로 최적화하여 컴파일한 10개의 표준화된 처리량의 비율(각각의 부동소수 벤치마크)의 기하학적 평균치
SPECfp_rate_base95: 각각의 벤치마크에 일반적으로 최적화하여 컴파일한 10개의 표준화된 처리량의 비율(각각의 부동소수 벤치마크)의 기하학적 평균치
각각의 벤치마크의 비율은 SEPC에서 제정한 기준시간과 벤치마크의 실행시간에 의해서 계산된다.
SPECint95, SPECint_base95, SPECfp95, 와 SPECfp_base95는 속도를 측정한다. 즉 컴퓨터가 한 개의 작업을 끝내는데 걸리는 시간을 측정한다. 다른 “비례’수치는 처리량을 측정한다. 즉 컴퓨터가 다중 작업을 처리하는 능력을 측정하는 것이다.
이제 SPEC92와 SPEC95 벤치마크에 실제로 무엇이 있는가 들여다 보기로 하자.
위의 코멘트는 또 수많은 벤치마크 프로그램을 비난하는 이유가 되기도 한다. 어플리케이션이나 벤치마크에서 컴파일러를 최적화함으로 인해 막대한 성능향상을 가져올 수 있다고 언급한 것을 기억하는가? 투명하고, 최적화되고 심사숙고해서 작성된 코드는 동급의 어플리케이션에서 단연 뛰어나게 할 수 있다(실제로 엄청난 마케팅 기술이나 실제적인 독점 또한 어플리케이션을 최고로 부각시킬 수 있다.). 그러므로 벤치마크용으로 어플리케이션을 사용하려 한다면, 매일 실제 사용하는 어플리케이션을 사용하는 것의 최선이다. 비슷하게 벤치마크용으로 어플리케이션들의 조합을 사용하려면, 매일 사용하는 어플리케이션들로 이루어진 것을 사용하는 것이 바람직하다. 만약 사용자가 3D 렌더링을 전혀 사용하지 않는다면 이것을 통한 벤치마크가 무슨 의미가 있겠는가? 각각 다른 렌더러(renderer)는 각각 다른 CPU에 따라서 다른 성능을 보인다, 그러므로 사용자가 사용중인 특정한 렌더러를 사용해야 한다. 다른 모든 소프트웨어도 마찬가지이다. 어떻게 이것이 코딩되고 코드가 어떻게 최적화 되었으며 컴파일 되었는지에 따라서 이것이 어떻게 실행되고 능력의 단계차이가 어떻게 나는지는 천차만별이다. 기본적인 개념은 사용자가 실행하지 않는(벤치마크할 때 제외) 프로그램의 성능은 실제 사용자가 사용하는 프로그램의 성능을 보여줄 수도 있고 보여주지 못할 수도 있다는 것이다. 그리고 실제로 사용자가 사용하는 프로그램의 성능만이 실제로 사용자가 관심을 가져야 할 부분이라는 것이다.
노트 : SPEC 벤치마크의 많은 커널들은 실제 일반적인 어플리케이션에서 볼 수 잇는 코드(Gaussian elimination, FFT, 등등)의 부분이라는 것을 밝혀둔다. 그러나 이 사실이 본인의 전체적인 관점을 돌리지는 못한다. 언급되었던 코드들은 항상 큰 어플리케이션의 일부분이고, 이것이 본인이 제시한 비판의 대상이 되는 것이다.
위 관찰에 대해서 생각해보자면, SPEC 벤치마크가 전체적이고 매우 많은 정보를 알려주는 반면에 , 뉴즈넷에서의 플랫폼간의 논쟁들을 제쳐두고 라서도, PC하드웨어에 관심있는 사용자들에게는 제한된 용도밖에 제공하지 못한다. 게다가, 우리 같은 PC류의 매니어들은 스스로 의 벤치마크를 하고 싶어하지만, SPEC벤치마크는 너무 비용이 많이 든다. SPEC65 CD-ROM은 새로운 고객이 구매할 경우약 600달러를 지불해야 한다. 그러므로 일반적인 실험실에서 SPEC 벤치마크를 볼 수는 없을 것이다.
결론
어떠한 벤치마크를 하던 간에, 전체적인 성능을 측정하는 데에는 현존하는 실제 어플리케이션만한게 없다. 구매자가 반드시 고려해야 할 주요 문제는 다음과 같다. 사용자가 필요한 어플리케이션을 얼마나 빨리 이 시스템이 처리할 것인가? 하는 것이다. 벤치마크는 꾸미고 치장될 수 있지만 실제 어플리케이션은 일반적으로 그렇지 않다. (본인은 게임이 조작되어서 인텔의 새로운 SSE를 사용시 더 좋은 프레임레이트를 보이는 것을 본 적이 있다. 그 스크린샷을 보면 SSE 가 가능한 버전은 낮은 폴리곤 숫자를 보여주는 것을 분명히 볼 수 있었다.) 어떠한 벤치마크들은 시스템의 한 두 부분만을 측정한다고 주장하기도 하지만, 실제로 사용자가 측정하고자 하는 것은 시스템의 성능이다. 하드웨어, 운영체제, 그리고 전부를 포함한 시스템을 벤치마크 하고 싶은 것이다.
업그레이드를 위하여 벤치마크 성적을 분석할 때 중요한 것 또 한가지는 현재 기계에서 얼마나 사용하는 어플리케이션이 빨리 실행되느냐는 것이지, 앞으로 출시될 운영체제, 즉 개발자들이 최근의 화려한 기술(SSE, MMX, 등등) 지원을 추가할 때에서 얼마나 빨리 돌아갈지 기대치가 아니라는 것이다. 만약 사용자의 즐겨 사용하는 어플리케이션이 아직 Intel의 새로운 확장기술을 지원하지 않는다면, 이러한 기술들에서 별 도움을 받지 못 받을 것은 뻔한 사실 아닌가? 만약 사용자가 6개월간의 지원을 기다리다가 6개월후에 단지 10%의 성능향상만을 볼 수 있다면?, 그냥 그것을 사지 말고 기다렸다가 높은 주파수의 CPU를 샀으면 어떠했을지 스스로 자문해 볼 만한 문제이다.
제품의 생명사이클이 너무나도 짧아서 업체가 약속한 것들이 실체화 되기 전까지 업그레이드를 미루는 것이 너무나도 어려운 것이 현실이다. 만약 독자중에 업그레이드 하려는 사람이 있다면, 잠시 멈추고 기다리다가, 업그레이드는 실제로 원하는 프로그램이 현존할 때, 이것에 기초해서 업그레이드를 해야 한다. 만약 앞으로 분명한 가격 하락이 있다면 물론 한달 정도 기다릴 수도 있을 것이다. 혹은 가격의 저하를 가져올 새로운 제품의 정확한 출시 일자를 알 경우도 기다릴 수 있을 것이다. 그러나 두, 세달 이상을 기다려야 할 경우에는, 왜 두세달을 더 못기다리는가. 항상 무언가 더 좋은 것이 나올 것이라는 사실을 알아 두어야 한다. 이 부분에서 좋은 벤치마크 결과가 필요한 것이다. 이것은 현재 어떤 물건을 사는 것이 좋으며 업그레이드를 위한 주문을 할 때가 언제인지 가르쳐 주기 때문이다.
그러므로 결국에는, 성능을 테스트하기 위한 방법은 한가지 밖에 없다. 첫째로, 모든 드라이버가 최근의 것이며 현존하는 것중에 가장 좋은 것인지 확인하라. 그리고 나서 가장 사용자가 즐겨 돌리는 어플리케이션을 실행시키고 이것을 실행시키는데 시간이 얼마나 걸리나 스톱워치로 시간을 재라. 물론 사람들이 통합적 벤치마크 프로그램을 앞으로도 계속 사용할 것임을 본인도 알고 있다. 그리고 이러한 프로그램들은 일반적인 어플리케이션이 하지 않는 표나 그래프, 수치적 성적을 보여줄 것이다. 사실은 우리 Ars Technica는 우리 스스로도 통합적 벤치마크 프로그램을 사용하는 것으로 알려져 있고, 앞으로도 이런 방법을 고수할지도 모른다. (Adobe같은 회사가 우리에게 공짜 소프트웨어를 제공하지 않는 이상 말이다…) 그러나 현실은 현재 실존하는 어플리케이션보다 좋은 벤치마크는 없다는 것이다.
온라인 게임이라면 엄청난 수의 몹이 있거나 꽉 찬 서버에 들어가 컴퓨터가 버벅일 정도의 상태에서 테스트해야 함.
게임이 10분 안에 오류가 나서 종료되거나 컴퓨터가 다운된다면 다시 바이오스로 들어가서 클럭값을 줄이거나 CPU 코어 전압(Vcore)을 한두단계 올려주면 된다.
CPU 코어 전압은 높을 수록 온도가 높아지고 소비전력도 늘어나기 때문에 자신의 컴 사용 용도에 맞춰 오버클럭하면 된다.
전압 한두단계 더 올렸다고 소비전력이 몇십와트씩 더 먹는건 아니다. 하지만 cpu코어 온도는 급상승하는 경우가 많다.
이런 급격한 온도상승은 cpu뽑기수율에 따라 그런 경우가 많다. 또 cpu 온도에 따라 최적 성능 안정성이 떨어지기 때문에 잘못된 오버클럭 후 실체감 성능이 더 나빠질 수도 있다.
그래서 오버클럭커들은 사제 cpu쿨링팬부터 알아보는 경우가 많다.
물론 성능과 발열, 소비전력 모두를 고려해서 최상의 결과를 얻을려면 그때부터는 오버클럭한다고 몇날을 밤새고 어느 순간 오버클럭커가 되어가는 자신을 발견하게 될지도 모른다.. ㅡㅡ;
일단 「이벤트뷰어」를 실행해놓고 게임을 실행한다.
게임 플레이 도중 다운되거나 오류로 튕겨나오면 오버클럭 실패고, 게임 중간중간 「Alt+Tab」 키로 바탕화면으로 빠져나와서 이벤트뷰어에 「WHEA-Logger」 오류가 하나라도 있는지 확인하면 된다.
게임플레이에는 아무 문제없지만 WHEA-Logger 오류가 하나라도 있다면 나가리다.
(whea-logger 오류 뿐만 아니라 이벤트 뷰어에 전에 없던 이상한 오류가 생겨도 오버클럭 관련 오류일 확률이 높다. 각종 하드웨어(특히 램) 관련 오류 뿐만 아니라 원인이 불분명하고 이상한 소프트웨어 프로그램 오류도 오버클럭 이후 종종 발생한다면 오버클럭 실패를 의심해봐야 함)
「HWMonitor」 프로그램을 실행해놓고 게임을 하면서 CPU 온도와 Vcore 전압값의 최대치를 확인한다.
그 후 이벤트뷰어 오류가 안나올때까지 바이오스에서 클럭값과 코어전압값을 이리저리 맞춰보는 식으로 하면 된다.
