`괴짜사용자` 시리즈: 프로세서 성능에 대한 고찰

"괴짜사용자" 시리즈: 프로세서 성능에 대한 고찰

Peter Seebach l 프리랜스 작가

시간이 감에 따라, 컴퓨터는 점점 빨라지고 있다고 얘기를 듣곤 한다. 그러나, 사용자들의 경험은 15년전에 비해 성능이 크게 향상되었다고 느끼지 못하고 있다. 저자인 Peter는 본 글을 통해 대부분의 프로세서 시간과 메모리가 어디에 사용되고 있는지 살펴보고 있다.

10년전쯤, 사람들이 매킨토시 컴퓨터상에서 Microsoft Word 가 너무 느리게 작동한다고 불평했던 것이 기억난다. 실제로 사용자는 이와 같은 큰 어플리케이션을 이용하면서 프로세서가 처리할 수 있는 것보다 더 빠르게 타이핑을 할 수 있었다. 그런데, 최근에도 이러한 상황이 여전히 발생하고 있다는 점을 발견했을 때, 나의 실망이 얼마나 컸을지 상상할 수 있을 것이다. 하나의 하드디스크를 가지고 있었던 내 최초의 컴퓨터는 1초안에 작은 명령행 유틸리티 하나를 로드했었고, 용량이 큰 그래픽 프로그램조차도 30초정도면 로딩했었다. 이들은 모두 좋은 스펙이었지만, 과거 15년동안 상황이 그리 크게 변하지 않았다는 것은 너무 슬픈 일이 아닌가?

여기서 궁금한 점은, "도대체 CPU 파워는 어디에 쓰이고 있는가?" 이다. 어떻게 1기가가 넘는 메모리를 가진 장비가, 15년전의 6메가정도의 메모리를 가진 장비에서 실행되는 어플리케이션의 속도를 내기에도 역부족일 수 있는 것인가? 이번 "괴짜사용자(The Cranky User)" 시리즈에서는 이 커다란 미스테리를 밝여볼 것이다. 이에 앞서 오래된 금언을 되새기고, 오늘날에 어떤 의미를 갖는지 살펴보자.

Moore의 법칙

Moore의 법칙은 잘못 인용되고 있는 것들 중 하나이다. 대부분의 전문가들은 컴퓨터는 18 개월마다 속도가 두 배로 증가한다고 주장하고 싶어한다. 사실 인텔 창립자 Gordon Moore는 1965년 컴포넌트 당 가장 싼 칩의 복잡함은 매년 두배로 증가했다는 것을 관찰했고, 이러한 트랜드는 약 10년간 지속될 것이라고 예견했다. 그런데 이것은 퍼포먼스가 두 배로 증가한다는 것을 의미하는 것은 아니다. 컴포넌트의 수가 그렇다는 것을 의미한다. Moore의 예견은 데이터에 의해 합리적으로 입증되었다. 1975년 그는 18 개월로 조정했으며 이것이 바로 대부분의 사람들이 요즘 인용하는 것이다.

재미있는 것은 Moore의 법칙은 시스템 디자인의 복잡함에 대해 언급하는 것 과는 달리 클럭(clock) 스피드에 대해서 많이 언급하지 않는다. 현대 CPU는 이전의 CPU와는 달리 많은 일을 수행한다. 예를 들어, 다중의 명령어를 동시에 실행할 수 있다. 또한 프로세싱 속도가 예견할 수 있는 비율로 증가한다는 것도 알려준다. 확실히 성능이 늘어났다.

놀라운 것은 대부분의 사용자들은 퍼포먼스가 15년 전에 비해서 확실히 나아진 것이 없다고 느낀다는 점이다. 이 프로세싱 시간에 대해 컴퓨터가 무엇을 할 수 있을까? OS X의 만화처럼 그려진 무지개 비치볼 커서에 대해 Usenet은 최면 같은 돌아가는 비치볼을 보느라 바쁘다고 논평했다.

농담은 집어치우고, 사실 컴퓨터는 과거 보다는 더 많은 일을 한다. 컴퓨터가 하는 일 중 대부분이 매우 미묘하고 사용자가 인지하는 영역 외에서 발생하고 있다. 많은 기능들이 자동화 되고 지난 칼럼에서 언급했듯이 이제 컴퓨터 없이 아무 것도 할 수 없다. 그리고 여전히 많은 것이 진행중이다. 요즘 컴퓨터 프로세싱 파워가 주로 어디에 쓰이는지를 살펴보자.

그래픽 디스플레이

현대적인 많은 시스템들은 텍스트를 렌더링하기 위해 반 앤티앨리어싱(antialiasing)을 사용한다. 이로서 텍스트 읽기가 쉬워지고, 저해상 모니터와 LCD 디스플레이의 가용성도 높아졌다. 단점은 반 앤티앨리어싱이 프로세싱 파워를 많이 소모한다는 점이다. 창이나 메뉴 뒤의 드롭 쉐도우 같은 시각 효과, 투명 메뉴와 효과, 실시간 효과 또한 많은 파워를 소모한다. 컴퓨터 메이커가 중점을 둬야 할 것은 대부분 사용자들이 이를 기대한다는 점이다.

예를 들어, 오래된 시스템에서는 비트맵 폰트를 사용했다. 이는 제공된 크기로 빠르게 렌더링 되었지만, 다른 크기로 보면 얼그러져 보인다. 대부분의 현대 시스템들은 실시간으로 아웃라인 폰트를 렌더링하는데, 현재 사용자들이 이를 사용하고 있다. 심지어 캐싱이 개입되어도 폰트 랜더링은 한 개 이상의 레이어의 프로세서 오버헤드를 추가한다. 하지만 어떤 벤더도 비트맵 폰트를 가진 인터페이스를 배포 하지 않는다.

현재 Mac 운영 체계는 비디오 카드의 렌더링 하드웨어가 추가 작업을 수행하도록 함으로서 그래픽 오버헤드 문제를 해결하고 있다. 비디오 카드는 두 번째 프로세서가 되고, 이로서 그래픽 프로세싱 시간이 줄어든다. 물론, 컴퓨터 인터페이스가 느려질 때는 대책이 없다.

안전과 보안

시스템 프로세싱 파워의 일정 부분은 애플리케이션의 향상된 안전과 보안 기능을 위해 사용된다. 대부분 최초로 어플리케이션은 안전성 체크에 많은 주의를 기울이지 않은 상태에서 작성되기 마련이므로, 이러한 기능의 상당수는 중요한 보안패치의 형태로 제공된다. 이러한 패치의 문제점은 시간이 지남에 따라 패치의 수가 점점 늘어난다는 것이며, 결국 각각의 패치는 시스템 성능에 크지 않은 영향을 미치지만, 이것들이 모이게 됨으로써 성능에 상당한 영향을 미치게 된다.

바이러스 스케너는 패치보다 더 많은 영향을 준다. 사용자의 일상적인 시스템 사용에 있어 바이러스가 중요한 요소로서 여겨짐에 따라, 개발자들은 바이러스를 물리치기 위해 더 많은 에너지(그리고 프로세싱 파워)를 소모하고 있다. 대부분의 바이러스 스캐너는 정기적으로 업데이트를 진행하며, 이 업데이트 작업은 작지만 무시하지 못할 만큼의 백그라운드 작업으로 진행된다. 아울러 업데이트후에는 이전보다 더 많은 파일들을 스캐닝하게 된다.

워드 프로세서용 매크로 바이러스가 존재한다는 점은 바이러스 스캐너가 실행 파일 뿐만 아니라, 데이터 파일도 스캐닝 해야 한다는 것을 의미한다. 결과적으로, 하나의 파일이 접근되기 전에 여러 차례의 스캐닝 작업이 일어나게 된다. 예를 들어, 다운로드된 파일은 그과정에서 일단 스캐닝을 거치게 되며, 압축파일이라면 그 내부의 파일들도 스캔된다. 또한 압축유틸리티를 이용하여 압축파일을 열어보거나 압축을 해제할 때마다 스캔작업이 일어나며, 압축이 풀린 파일을 열어볼때도 다시 스캔을 하게 된다.

이 모든 스캐닝에 많은 프로세싱 시간이 걸리고, 이것 때문에 시스템에서 실행되는 모든 프로그램에 영향이 미친다. 예를 들어, 많은 그래픽 파일을 사용하고 이들을 로딩하는 비디오 게임은 1시간 플레이 동안 12번 스캔되어야 할 같은 파일이 20MB나 된다.

보안은 프로세싱 파워를 사용할 만한 가치가 있고, 또 사용해야 한다. 대안이라고 하는 것은 더 나쁜다. 스파이웨어와 바이러스는 어마어마한 양의 시간을 소비한다. 컴퓨터가 느려지는 또 다른 원인은 트래픽 상에 있는 프로그램, 팝업 광고 등이다.

복잡한 프로그램

복잡한 프로그램은 느려진 프로세스의 가장 큰 용의자일 것이다. 애플리케이션이 복잡해지면서 코드도 더 많아지게 된다. 내가 지원 코드라고 부르는 이 코드는 개발자가 프로그램을 쉽게 작성하도록 도와준다. 매우 큰 프로그램은 중첩된 레이어의 지원 코드와 결합한다. 예를 들어, Mozilla의 리눅스 구현은 30개 또는 다른 지원 코드로 연결된다. Mozilla가 직접 사용하는 지원 코드를 위한 지원 코드도 포함해서 말이다.

일반적으로 코드 자체는 자신의 임무수행에 매우 효율적이며, 규모가 큰 어플리케이션 개발을 수월하게 한다.그러나 이러한 작은 코드 조각들이 예정된 방식으로 상호작용하도록 만들기 위한 추가코드는 또 다른 실행비용을 필요로 하게 된다. 다시한번 말하지만, 이렇게 반복되는 작은 비용들이 쌓여, 시스템 성능에 중대한 영향을 미치게 된다.

Windows에서 사용하는 몇몇 프로그램들은 시스템 시작 시 특별한 프로그램을 실행한다. 이들 각 프로그램들은 각자의 공유 라이브러리를 미리 로딩해서 프로그램은 보다 빠르게 시작된다. 응답성이 높은 내 시스템의 경우 이것을 사용할 때 지연 시간은 5분이다. 이유는? 이것은 십여 개의 프로그램을 실행하여 프로그램 로딩을 빠르게 했기 때문이다. 아이러니는 그 당시에도 이상하지 않았고 지금도 마찬가지라는 점이다.

결론

어느정도의 코드 증가는 최근의 복잡한 경향을 고려하면 어쩔수 없는 것일 수 있다. 이글에서는 그중 몇가지 주요 요인에 대해 이야기했다. 실제로는 사용자에게 별로 유용하지 않은 추가작업을 하기위해 프로세서를 필요로 하는 어플리케이션들, 누구도 이해하지 못하고 시스템이 요구하지 않음에도 실행되는 지원코드들, 어플리케이션의 빠른 개발에만 치중하느라 안전성이 부족하여 발생하는 수많은 패치들이 여기에 속한다. 이러한 문제의 주요한 원인중 하나는 제때에 시장에 출시해야 한다는 지나친 강조를 들 수 있다.

다른 원인으로는 소위 Second-System 효과라는 것을 들 수 있다. 이것은 Frederick Brooks가 "The Mythical Man-Month"라는 글에서 처음 논의한 내용으로, 개발자들이 두번째 프로젝트를 수행하면서 잘 만들고자 하는 의도하에 제대로 고려되지 않은 기능들을 포함함으로써, 시스템이 쓸데없이 비대해지게 된다는 것이다. 불행하게도 오늘날 널리 사용되는 상당수의 시스템이 Second-System에 속한다. 더 심각한 것은 Second-System 디자인에 의해 비대해진 시스템이 다음 버전에서의 호환성 유지를 위해 그대로 유지되고 있다는 점이다.

다행히, 최악의 상황은 끝난 것처럼 보인다. 800-Mhz 이상의 빠른 프로세서가 세상에 나오면서, 사용자는 계속된 업그레이드의 필요성이 줄어 들었다. 오늘날 대부분의 사용자들은 컴퓨터가 수행하고 있는 작업이 완료되기를 기다리며 여러시간을 소비할 필요없이, 자신의 작업을 더 빠른시간내에 마무리 할 수 있다.

이번 주 수행 목표: 몇 개의 애플리케이션을 동시에 시작하고 시작 시간을 측정하라. 5년 동안 이를 반복하고 시간이 지나면서 이것이 나아지고 있는지를 확인하라.

참고자료

◆ Everything's automated! (developerWorks, January 2005).

◆ Usability vs. security (developerWorks, August 2002).

◆ A peek through the veil at 2005 (developerWorks, January 2005).

◆ History of chipmaking at IBM (developerWorks, March 2004).

◆ Reducing the user interface (developerWorks, June 2001).

◆ Moore's Law.

◆ second-system effect.

◆ Global Services Usability Engineering team

◆ Web Architecture zone

◆ Browse for books

제공 : DB포탈사이트 DBguide.net