성능 논의 지속

  • [アーティクル]

 

 

이 블로그에서 성능에 대해 여러 번 다뤄왔습니다. 최근에는 많은 사람들이 이 주제에 대해 블로그나 문서에서 다루고 있습니다. 이것은 이 블로그를 읽고 계신 여러분들도 매우 흥미로울 것이라고 생각합니다. 성능에 대해 어떻게 생각하고 개발을 하는지 여러 가지 에피소드에 대해 좀 더 많은 정보를 제공을 드리고자 합니다. 물론, 저도 최근까지 매우 낮은 사양의 머신을 사용했기 때문에 성능은 개인적으로도 중요한 문제입니다. 다만, 현재 이 블로그는 크리스마스 선물로 본인에게 선물한 것을 집에서 사용하고 있습니다. 64 비트의 일체형 데스크톱으로, CPU 는 Quad Core, discrete graphic, 메모리 8GB,RAID 가 탑재되어, 초기설정을 끝내자마자 업그레이드된 새로운 Windows 7 빌드가 운영됩니다. 이 글은 Michael Fortin 과 함께 썼습니다. --Steven

베타는 아직 완성되지 않았지만, 벌써 많은 분들이 벤치마크를 시작하여 시험을 하고 있습니다. 만약을 위해 말씀 드리지만, 출시 이전 빌드의 벤치마크 테스트는 좀 더 기다려 주시기를 바랍니다. 이렇게 말씀 드려도 많은 사람이 여러가지 판단을 내려야 한다는 것을 알고 있습니다. 동시에 출시전의 코드 상황인 것을 사람들에게 알려 주기 위해, 시간을 들여주신 분들에게 감사 드립니다. 무엇보다도, 현재 많은 분들이 좋은 결과를  볼 수 있다는 것을 기쁘게 생각합니다. Windows 7 의 모든 기초적 능력이나 사람들이 기대하는 새로운 기능이 제품이 완성했을 때는 한층 더 큰 기쁨이 될 것이라고 믿고 있습니다.

이 블로그에서 성능에 대해 쓰는 것은 그것을 측정한다라는 것처럼 미묘한 일입니다. 방향성을 보여주는 의지 표명이 우리의 의도 이상으로 받아 들여지는 것을 보았습니다. 또 동시에 성능 측정 방법은 한편으로 무한대라고 생각될 만큼 많고, 같은 데이터의 파악방법도 다양합니다. 결국, 성능은 각개인이 느끼는 것이라고 말할 수 있는 것이 아닐까 생각했습니다. 적절한지 우수한지는 시나리오나 개인에 따라서 변합니다. 지금까지 받은 메일 중에서 성능에 대해 명백한 것이 있었습니다. :

 

  • 모든 응용 프로그램 (열어서 로드하는 응용 프로그램) 를 매우 빠르고 실행하고.특히, 많은 것을 동시에!!!!! 따라서 모두에게 대규모 멀티 코어 (quad-octa core CPU) 와 GPGPU 를!!!!!!!!!!!!
  • 지금이 그 때입니다. 사용자는 스피드를 원하고 우리는 스피드를 줄 수 있습니다.
  • 1.5GHz 의 Intel Atom CPU (싱글 코어) 와 메모리 1GB 를 탑재한 Acer의 NetBook 「Aspire One」에서 Windows 7 을 매우 빠르게 움직이면서, 그래픽도 제대로 된 한 것을 보고 싶다.
  • Windows 7 에서는 GUI 와 심장부의 향상 (대규모 멀티 코어 + 64 비트 + Direct 11…최고의 성능 등)을 포함하여, 플립 3D 기능을 개조해 주었으면 한다!!!!! 플립 3D 기능을 Windows 7 에서 효과적 이며 실용적인 것으로 했으면 좋겠다.
  • 성능에 대한 것으로 많은 폰트를 설치 할 때 불편함을 줄여주는 방법을 찾아내 주세요.
  • 성능, 실행, 검색 스피드 및 UI 경험에서 Windows 차기 버전에서는 새롭운 혁신적인 무엇인가를 가져왔으면 좋겠습니다. HP Touch Smart PC 의 새로운 UI 을 사용해 보았지만, 그들은 터치 인터페이스 컨트롤은 훌륭합니다.
  • Windows Vista 보다 성능이 월등히 향상되기를 바랍니다.
  • 많은 사람들이 바라는 최대 기능은 성능입니다.

이러한 주석에서 성능은 사람에 따라서 각각 다른 의미를 가진다는 것을 알 수 있습니다. 사용자 인터페이스 담당자는 잘 알고 있지만, 지각된 성능과 실제 성능은 자주 다들 때가 있습니다. 제(Steven)가 Windows UI 의 일부를 Visual C++를 쓰고 있고, Borland C++ 와 벤치마크를 비교 했을 때, 우리는 확실히 빨랐지만(초 단위 측정), 비교 문서에서는 항상 Borland 가 빠르고, 컴파일로 처리된 행수의 형식에서 결과를 표시한다고 합니다. 그래서 저는 컴파일 중에 몇 번이나 점멸하는 행수를 표시하는 코드를 넣었습니다 (문자 그대로 반짝반짝 점멸하여, 이제 안 된다고 말하는 것처럼 보였습니다).시계 시간으로는 실제로 그 처리에 시간을 소비하여, 그 만큼 「늦어진다」는 것이지만, 반대로 이번은 우리가 빠르다는 칭찬을 받았습니다. 즉, 이 경우에서는 늦게 볼 수 있던 것이 실제로는 빨랐던 것입니다.

또, 이것과 반대의 이야기가 과거에 있었습니다. Microsoft Word for DOS 스크롤 속도에 대한 것으로(Excel for Windows에서도 같습니다)  초기 무렵, Bill Gates 는 언제나 눈에 보이는 성능 강화를 추진했지만, 스크롤 속도는 언제나 충분한 스피드에 이르지 않는 한가지였습니다. 머리 좋은 사람들이 모여 이 문제에 열심히 고민한 결과, 이번은 스크롤이 너무 빠르게 되었습니다. 문자 그대로, 감속하지 않으면 안 될 정도 입니다. 그렇지 않으면 [Page Down] 키를 누르는 것만으로, 항상 문서의 첫번째 페이지에서 마지막으로 갔습니다. 빠른 것이 좋은 일이지만, 가끔 「너무 빠른」경우도 있습니다.

 

보다 좋은 성능을 위해서, 무엇을 오프로 하거나 조정하거나 하는 것이 좋은지 피드백을 받았던 적이 있습니다. 또, 성능이 생각했던 것보다도 좋지 않은 원인을 찾고 싶다는 분들도 있습니다. 최근 저는 새로운 노트 PC 의 성능 문제를 밝히고자 하는 분과 전자 메일을 교환했습니다. 이야기를 들을 때에 그 노트 PC 는 매우 「클린」 (프로세스는 40까지, 탑재 메모리 1GB 의 반은 프리, 유휴 상태로 CPU 사용율은 5% 미만)한 상태 라는 것을 알 수 있었습니다. 그리고, 한층 더 알아본 결과, 인터넷 접속 (전화 접속)이 그 시스템에서의 가장 큰 병목 상태였다는 것이 판명되었습니다. 많은 사람이 애니메이션이나 그래픽, 또 색조차도 오프로 하는 것을 추천합니다. 그것은 이것들이 성능의 근원이라고 믿을 수 있기 때문입니다. 레지스트리, 디스크 영역 활용, 색의 깊이에 대해 사람들이 성능 문제의 가능성이 있다고 생각하는 주제를 다뤘습니다.

성능은 본질적으로 시간과 공간의 절충 (SF 대신, 컴퓨터 과학적으로)으로, 노트 PC에서는 한층 더 전력 소비 (또는 CPU 활용)의 측면이 있습니다. 메모리가 무한하다고 가정하면, 물론 많은 알고리즘은 지금 있는 것과는 완전히 다를 것입니다. 유한한 메모리에서는 성능이 전체적인 일련의 시나리오에 크게 영향을 받습니다. 때문에 많은 경우에서는 성능에 대해 이야기할 때는 시계 시간에 대해 이야기하는 것과 같은 정도, 메모리의 소비량 삭감과 관련됩니다. OS 일부는 메모리 사용량의 관점에서는 훨씬 더 조절 가능하게 되어 있어 그 결과, 시스템 전체의 성능이 향상합니다 (적은 페이지로 해결되기 위해).시스템 외 부분은 실행되는 명령의 수가 관계합니다 (거의 모든 오퍼레이션은 코드 경로를 통과하기 위해).우리는 두 가지 모두 상당한 작업량을 할애하고 있습니다!

성능 측정 및 향상의 현실은 Windows 7 에서 우리가 몇가지 「수준」에 집중하고 있는 것입니다. 그것들은 마이크로 벤치마크, 특정 시나리오, 시스템 튜닝에서 Windows 7 을 어떻게 설계할지에 대해 각각 중대한 역할을 이루어 있습니다. 어느 것이나 측정 가능하지만, 어떤 것이나 하나의 측정에서 시스템 성능을 간단하게 결론짓는 것은 사실과 다릅니다.

 

마이크로 벤치마크(Micro-benchmark) .마이크로 벤치마크는 테스트의 일종으로, 특정 하위 시스템에 대하여 극한 수준까지 스트레스를 줍니다. 이것은 자주, 매우 고속으로 전체 실행시의 일부 시간밖에 차지하지 않는 듯한, 사용시의 성능을 보는 것이 곤란한 코드 영역입니다. 테스트는 시스템의 일부에 스트레스를 추가하는 것과 같이 설계됩니다. 시스템이 많은 파트는 마이크로 벤치마크의 대상입니다. 예를 들어, 파일시스템, 네트워크, 메모리 관리, 2D 및 3D 그래픽 등입니다. 좋은 예로서 고속 파일 복사를 가능하게 하는 작업이 있습니다. 파일을 복사할 때는 (상당한 ) 수많은 조건의 요인이 되는 하위 코드가 다수 존재합니다. 그리고, 이 코드는 커멘드 윈도우 (또는 API)로 XCOPY 를 개입시켜 가장 직접적으로 실행됩니다. 물론, 복사 작업의 대부분은 탐색기에서 행해져 진행상황 표시, 취소할 수 있도록 하기 위한 작업, 복사 중에 바이트 수 계산 등도 함께 행해집니다. 이러한 모두에는 어느 정도의 비용을 지불하지 않으면 안됩니다 동시에 거기에 따라 이익도 있습니다. 마이크로 벤치마크의 목적은 최선의 경우를 잘 이해하여, 가장 사용에 적절한 경우와 비교하는 것입니다. 고급 사용자는 보다 권한이나 컨트롤, 유연성을 얻기 위해서, 언제나 명령줄을 사용합니다. 마이크로 벤치마크의 결과 향상에 의해, 시스템 성능을 측정하기 쉽습니다. 그러나, 몇 번이나 반복하지만, 특정 사용 방법은 훨씬 광범위한 코드 경로에 이르러, 시간도 다양한 장소에서 소비되므로 이것은 부적절하다는 것을 압니다. Internet Explorer 8 에서 스크립트 성능에 관련한 이런 종류의 문제를 논했던 성능에 대한 글을 썼습니다. 한편 그 반대로, 하위 시스템에서는 마이크로 벤치마크에 의해서 성능을 측정할 때, 주의 깊게 해야 하는 것인 것을 우리는 잘 이해하고 있습니다. 예를 들어, DirectX 그래픽 성능은 게이머를 목표로 하는 분야입니다. 또, 많은 마이크로 벤치마크는 Windows OS, 하드웨어, 특정 드라이버 편성에 의존하는 것도 주목할 만합니다.

 

특정 시나리오. 대부분의 사람은 부팅, 대기/다시 시작, 일반적인 응용 프로그램 실행이라는 높은 수준의 동작을 개입시켜 PC 성능을 실감합니다. 이것들은 과거에도 채택했던 주제입니다. Windows 7 설계에서는 각 팀이 개선하고 싶은 특정 시나리오에 초점을 맞추었습니다. 이런 종류의 작업은 꼼꼼한 설치나 추가 도구를 필요로 하지 않고 검증할 수 있는 것입니다. 이 작업에는 실행되는 수많은 명령의 코드 경로를 튜닝하거나 자주 있는 경우를 위해서 배포된 데이터를 보거나 모든 OS 의 API (예를 들어, 레지스트리 검색 등)를 이해하는 것이 포함됩니다. 예로서 USB 장치를 다시 넣는 시간을 줄이기 위해서 계속하는 작업이 있습니다. 이것은 특히 UFD (USB 플러시 장치)나 메모리카드에 대해서 현저합니다. Windows 는 전체의 하위 시스템이 특정 카드 리더나 UFD 용의 고유 드라이버에 의해서 정밀 조사 되는 것을 허가합니다. 비록 대부분의 경우 같아도, 우리는 에코시스템의 다양성에 대해 책임을 지지 않으면 안됩니다. 프로젝트를 시작할 때, UFD 가 삽입될 때에 실행되는 코드의 완전한 프로파일을 확인하여 이 시나리오에 구석에서 구석까지 살펴보았습니다. 그 후, 체계적으로 각각의 「핫 스폿」을 극복해 나갔습니다. 또, 이 선에 따른 다른 예로서 저장소 하위 시스템 뿐만이 아니고 그래픽서브시스템도 관계하는 DVD 영화의 재생을 들 수 있습니다. 이 시나리오의 좋은 점은 전력 소비에 영향을 주는 CPU 이용에 대해도 최적화하고 싶어지는 것입니다.

 

시스템 튜닝. 상당한 양의 성능 작업이 시스템 튜닝과 관련됩니다. 이 분야에서 실시하고 있는 작업을 확인하기 위해, 우리는 정기적으로 시스템의 전체적인 성능을 이전 빌드나 이전에 출시한 Windows 와 같은 테스트와 비교합니다. 그리고, 많은 시간·영역·전력을 소비하는 오퍼레이션이나, 이러한 차원의 어느 쪽이든 「성장」이 있는 오퍼레이션을 없애기 가능한 것을 찾고 있습니다. 또, 빌드별로 테스트를 실시해서, 기능이 저하되지 않은지 확인하는 것과 동시에 각 개발자는 자신의 담당 영역이 좋아지도록 책임을 지고 있습니다. 우리는 개선을 위해서 할 수 있는 것이 없는지, 모든 수단을 동원하여 조사하고 있습니다. Pre-Beta 또는 베타 버전의 Windows 7 을 사용해 보고 많은 사람이 곧바로 깨닫는 것의 하나에 데스크톱 윈도우 관리자의 메모리 사용량 (작업 관리자로 측정되므로, 그것 자신의 측정값은 오해 받을지도 모릅니다)이 있습니다. Windows 7에서는 방대한  아키텍처 작업이 하위 시스템에 의해서 소비되는 메모리량을 줄이기 위해서 투입되었습니다. 이 작업은 Windows Vista 용 드라이버와의 호환성을 유지하면서 실행되었습니다. 같은 작업을 데스크톱 검색 엔진에 대해서도 가서, 메모리 뿐만이 아니라 I/O 의 발자국(리소스 소요량)도 줄였습니다. 무엇보다 복잡했던 작업의 하나로 작업 표시와 시작 메뉴가 개선되었습니다. 이 개선에는 중대한 부분 (코드의 「저해」영역)이나 레지스트리 I/O, 전체 코드 경로에 대한 상당한 작업이 발생했기 때문입니다. 이 작업의 목적은 UI  요소가 항상 이용 가능하고 잘 움직이도록 하는 것이었습니다.

응용 프로그램의 선택 사용자 인터페이스를 추진하는 포괄적인 성능의 측정 방법도 있습니다. 그것들은 다른 기초적인 하드웨어 또는 드라이버를 같을 버전의 Windows 에서 비교하는데 가장 적합합니다. 그 이유는 자동화 그 자체가 자주 버전에 의존하기 때문에 자동화는 자연스럽지 않은 방법으로 행해져, 실제로 느껴지는 성능 변화 대신, 이 차이를 측정하는 경향에 있습니다. 전형적인 예로서 드롭 다운 메뉴를 드로잉하기 위한 코드 경로가 있습니다. 더 액세스 하기 쉽게 하거나 매력적으로 하기 위해 메뉴에 명령을 추가하면, 훨씬 빠른 스피드로 메뉴 구동하는 자동화된 시스템에서는 「성능」 변화를 알 수 있을지도 모릅니다. 만약을 위해 말씀 드리지만, 이런 종류의 상황에서는 마이크로 벤치마크 효과는 실제 사용 패턴 과는 모순된 형태로 증대 됩니다.

다양한 측정 방법으로 초점을 맞추고 생각하면, Windows 7 에 대한 종합적인 목적은 사용자의 여러분이 기대에 따른 시스템을 체험하는 것은 중요합니다. 성능의 사고 방식은 특정 벤치마크의 결과와 같은 정도 중요합니다. 그리고, 성능의 전체상 배치를 근거로 해서 작업하고 있는 것을 확실한 것으로 하기 위해, 앞에서 한 얘기와 같이 폭넓은 도구에 대해서 주의해야 합니다.

폭넓은 전략에 덧붙여 우리가 도입하고 있는 특수한 도구가 있습니다. 그 하나가 PerfTrack 라는 도구로, 성능에 관해서 데이터 역할을 다음의 수준에 가지고 가므로, 베타로 중요한 역할을 완수합니다.

 

  • 몇 천 가지 다양한 경우를 측정하기 위한 일련의 테스트 코드를 생성하여 보수해 왔습니다. 이것을 개발자가 체크인 하기전에 실행하여, 빌드를 스스로가 설치하여 사용할 수 있는 수준으로  성능이나 반응을 유지합니다. 이러한 게이트는 매일매일의 빌드 성능과 반응이 몇천명이  장기간 Windows 7 을 메인 시스템으로 실행하고 일상업무를 실시하는데 필요 충분한 수준으로 유지합니다.
  • 서비스 비용을 줄이고, 주요한 코드 경로의 효율을 높여 확장성을 향상하기 위해서 리팩터링하여, I/O 의 효율을 높이고 그 외에도 여러 가지 왔습니다. 원격 측정에 의해서 일반적이라고 판명된 현실세계의 실행 패스에 근거한 시나리오 주도형입니다.
  • 주요한 PC 배급업체, 소프트웨어 배급업체, 하드웨어 제조업체와 긴밀한 파트너 관계를 만들어 왔습니다. 우리의 도구를 일반적으로 공개하여 다수의 트레이닝 세션을 마련했습니다. 그리고, 사용자 여러분이 어려운 설정을 필요로 하지 않고, 배터리 지속 시간도 오래되고 훌륭한 능력의 시스템을 입수하는 것을 목적으로 시스템을 출시하는 것에 중점을 두었습니다.
  • Windows 개발 팀에서는 단순한 트레이스 캡처 도구를 전원 데스크톱에 설치했습니다. 이 데스크톱 도구는 성능의 트레이스를 유효하게 하여 24 x 7 (1일 24시간, 주 7일) 실행할 수 있습니다. 만약 무언가가 늦어지거나 하면, 마지막 행동을 기록하여 자동 분석에 데이터를 보내기. 또한 팀의 사람들은 새로운 문제나 자동화 테스트에서 아직 판명되지 않는 문제가 없는지, 직접 트레이스 결과를 점검합니다. 트레이스 결과는 정보량이 매우 풍부하고, 거의 항상 중대한 문제의 근원을 찾아내는데 도움이 됩니다.
  • 모든 Pre-Beta, Beta 및 RTM 판의 사용자의 여러분을 위해서, 우리는 새로운 유형의 계기를 개발하여, 운영 체제와 미리 설치된 있는 응용 프로그램의 500이상의 장소를 측정하는데 사용했습니다. 새로운 계기는 컨셉은 단순하지만, 결과는 획기적입니다. 이 도구가 PerfTrack 로, 클라이언트의 벤치마크 테스트는 실제 사용자의 반응 문제에 대해 그다지 참고되지 않는다는 신념을 증명하는데 도움이 되었습니다.

 

Perftrack 는 매우 유연하고, 적은 오버헤드로 동적으로 설정 가능한 원격 시스템입니다. Windows 7 을 통한 주요한 시나리오로, 시나리오를 하나로 통합하는 시작」과「정지」의 이벤트가 있습니다. 시나리오는 어떤 것이든 가능합니다. 예를 들어, 파일을 여는 웹 페이지를 열람하는 컨트롤 패널을 여는 문서를 검색하는 컴퓨터를 실행 하는 일반적인 일도 있습니다. 반복이지만, Windows 7 의 베타에서는 500 이상의 시나리오가 측정되었습니다.

분명하게, 정지와 시작 이벤트간의 시간은 시나리오의 반응을 나타내고 있어 분석을 위해서 이 지표를 우리의 곳까지 보내기 되돌리는데, 원격 측정의 인프라를 사용하고 있습니다. Perftrack 의 독자성은 단지 무엇을 측정할까 뿐만이 아니고, 문제가 있는 응답 시간의 발생을 단지 관찰하는 이상이 할 수 있는 점에 있습니다. Perftrack 는 트레이스의 형태로 보다 많은 정보를 「전화 접속」요청 할 수 있습니다.

아래와 같은 분포를 생각해 봅시다. 그리고 시나리오는 XYZ 를 여는 것으로 합니다. 선택한 목표에 대해서, 초록은 허용범위 안의 시간을 나타내, 황색은 빠듯이 OK 로 간주하는 시간을 나타내고, 빨강은 낮은 성능을 의미합니다. 시간은 밀리초 단위로, X 축으로 따라 표시됩니다. Y 축은 히트 카운트를 나타냅니다.

Graph measuring responsiveness goals and real world data.

 

보시면 알 수 있듯이 시나리오가 완료하기까지 5초 이상 걸리는 경우가 많이 있습니다. 이런 종류의 분포에서는 성능 팀은 과거에 시간이 걸리는 「열다」커멘드를 체험한 것이 있는 시스템에서의 100 이상의 트레이스를 「전화 접속」하여 요청 하는 것을 추천합니다. 「전화 접속」리퀘스트에서는 우리가 흥미롭게 생각하는 「반응을 일으키는 최소 물리량」의 시간을 설정합니다. 또한 일정량의 메모리를 탑재하고 있는 특정 클래스의 프로세서를 탑재하는 특정 드라이버가 존재하는 등의 조건으로 머신에 필터를 걸기도 합니다. 그리고, 조건을 만족하는 클라이언트는 「시작」이벤트에 이른 시점에서, 빠르게 트레이스 할 수 있도록 설정되어 만약 「정지」이벤트가 설정한 「반응을 일으키는 최소 물리량」의 시간 이후 발생하면, 우리에게 반환될 가능성이 있습니다.

상상대로, 상당양의 엔지니어링 작업은 원격 측정과 피드백의 시스템이 기능하는 것을 위해서 소비됩니다. 모든 Windows 개발 팀은 이 시스템을 구현하기 위해서 공헌하여, 이미 기본적인 부분은 완성되어 앞으로 지금보다는 적은 노력으로 가능할 것 입니다. 

트레이스와 거기에 따라 밝혀진 지극히 현실적인 문제의 수정에 중점적으로 임한 결과, 실제 반응으로 놀라우 개선을 볼 수 있어 Windows 7 에 대한 수많은 칭찬을 얻었습니다. 추가적으로 트레이스는 우리가 오랫동안 그렇다고 믿어 온 것을 증명하는데도 도움이 된 것을 지적하고 싶습니다.

이 글에서는 성능에 대한 우리의 생각을 소개하고, Windows 7 의 엔지니어링을 통해 어떻게 측정할지 세부 사항에 대해 소개했습니다. 베타 기간 중, 우리는 목표를 달성하기 위해 보다 좋은 원격 측정을 계속 실행할 예정입니다. Windows 7 에서 사용자의 여러분에게 기대에 부응하는 성능을 체험하실 수 있을 것이라고 믿고 있습니다.

앞으로 많은 사람이 스톱 워치나 마이크로 벤치마크를 계속 사용하여 자동검사를 계속 실행할 것입니다. 이것들은 각각, 자기 자신으로 실시하는 분석이나 우리의 엔지니어링에서 적합한 장소입니다. 여러분의 흥미를 근거로 하면서, 우리가 어떻게 사물을 측정하여, 어떻게 제품을 개발할지에 대해 한층 더 이야기할 수 있기를 바랍니다. 

--Steven and Michael

Published Thursday, January 22, 2009 7:03 PM by e7blog

Filed under: Perf