パフォーマンスに関する議論の続き

このブログでパフォーマンスについて幾度かお話してきました。最近では、多くの人々がこのトピックについてブログや記事を書いています。それは、このブログを読んでいる人たちにとっても大変興味深いものであると思います。そこでパフォーマンスということに対して私たちがどのように考え取り組んでいるか、その舞台裏についてもう少し情報提供をするべきだと考えました。もちろん、私も最近までとても低スペックのマシンを使用していたので、パフォーマンスは個人的にも重要な問題です。ただし、別の意味でお知らせしておきますが、私は現在このブログを自分へのクリスマスプレゼントである自宅用マシンで書いています。そのマシンは 64 ビットの一体型デスクトップで、 CPU はQuad Core 、単体グラフィック、メモリ８GB 、 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 7 が Windows Vista よりもパフォーマンスが劇的に向上することを祈っています。
• 多くの人々が望んでいると思われる最大の機能はパフォーマンスです。

これらのコメントから、パフォーマンスは人によってそれぞれ違う意味を持つことがおわかりいただけるかと思います。ユーザー インターフェース担当者はよくわかっているのですが、知覚されたパフォーマンスと実際のパフォーマンスはしばしば異なるものです。私 (Steven) が Windows UI の一部を Visual C++ で書いていて、Borland C++ とベンチマークを比較したとき、私たちは確実に速かった (秒単位で測定) のですが、批評記事では常に Borland の方が速く、コンパイルで処理された行数の形式で結果を表示すると言われていました。そこで私は、コンパイル中に何度も点滅するような行数を表示するコードを入れました (文字通りピカピカ点滅するので、もうダメだと言っているように見えました)。クロック時間では実際にその処理に時間を費やすので、その分「遅く」なったわけですが、逆に今度は私たちの方が速いと賞賛されるようになりました。つまり、このケースでは、遅くみられたものが実際には速くなったのでした。

また、これとは反対の話が過去にありました。それは Microsoft Word for DOS でのスクロール速度についてです (Excel for Windows でも同じことがありました)。まだ初期の頃、Bill Gates はいつも目に見えるパフォーマンス強化を推進していましたが、スクロール速度はいつまで経っても十分なスピードに達しないもののひとつでした。頭の良い人たちがこの問題に一生懸命取り組んだ結果、今度はスクロールが速過ぎるようになってしまいました。文字通り、減速しないといけないくらいに、です。そうでないと、[Page Down] キーを押すだけで、いつも文書の 1 ページ目から最後に行ってしまうのでした。速いことはよいことですが、たまに「速すぎ」ということがあります。

より良いパフォーマンスのために、何をオフにしたり調整したりするのが良いかというフィードバックをいただいたことがあります。また、パフォーマンスが思ったよりもよくない原因を見つけたいという方々もいらっしゃいます。最近私は、新しいノート PC でのパフォーマンスの問題を突き止めようとしている方と電子メールで会話しました。話を聞くうちに、そのノート PC はとても「クリーン」 (プロセスは 40まで、搭載メモリ 1GB の半分はフリー、アイドル状態で CPU 使用率は 5% 未満) であることがわかりました。そして、さらにやりとりした結果、実はインターネット接続 (ダイヤルアップ) がそのシステムでの一番のボトルネックだったことが判明しました。多くの人がアニメーションやグラフィックス、さらには色すらもオフにすることを推奨しています。それは、これらがパフォーマンスの根源であると信じられているからです。レジストリ、ディスク領域の活用、そして色の深みについて、人々がパフォーマンス問題の可能性があると考えているトピックとして話しました。

パフォーマンスは本質的に時間と空間のトレードオフ (SF ではなく、コンピューター サイエンス的に) で、ノート PC においてはさらに電力消費 (または CPU 活用) の側面があります。メモリが無限と仮定すると、もちろん、多くのアルゴリズムは今あるものからまったく違ったものになるでしょう。有限のメモリでは、パフォーマンスは全体的な一連のシナリオに大きく影響を受けます。そのため多くのケースでは、パフォーマンスについて話すときは、クロック時間について話すのと同じくらい、メモリの消費量を削減することに関連しています。OS のある一部は、メモリ使用量の観点でははるかに調節が可能になっており、その結果、システム全体のパフォーマンスが向上します (少ないページングですむため)。システムの他の部分は、実行される命令の数が関係します (ほとんどすべてのオペレーションはコード パスを通るため)。私たちはこのどちらについても相当な作業量を割いています!

パフォーマンスの測定および向上の現実は、Windows 7 で私たちがいくつかの「レベル」で集中しているものです。それらは、マイクロ ベンチマーク、特定のシナリオ、システム チューニングで、Windows 7 をどう設計するかにおいて、それぞれ重大な役割を果たしています。どのひとつをとっても測定可能ですが、どれかひとつの計測からシステムのパフォーマンスを簡単に結論付けるのは事実と異なります。

マイクロベンチマーク。マイクロ ベンチマークはテストの一種で、特定のサブシステムに対して極限レベルまでストレスを加えます。これはしばしば、とても高速で全体の実行時のほんのわずかな時間しか占めないような、使用時のパフォーマンスを見るのが困難なコードの領域です。テストはシステムの一部にストレスを加えるように設計されています。システムの多くのパーツはマイクロ ベンチマークの対象です。たとえば、ファイル システム、ネットワーク、メモリ管理、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 または 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 を通した主要なシナリオで、シナリオをひとくくりにする「開始」と「停止」のイベントがあります。シナリオはどんなものでもあり得ます。たとえば、ファイルを開く、Web ページを閲覧する、コントロール パネルを開く、ドキュメントを検索する、コンピューターを起動する、といった一般的なこともあります。繰り返しになりますが、Windows 7 のベータでは500 以上のシナリオが計測されました。

明らかに、停止と開始イベント間の時間はシナリオの反応を示しており、解析のためにこの指標を私たちのところまで送り戻すのに、遠隔測定のインフラを使っています。Perftrack の独自性は、単に何を計測するかだけでなく、問題のある応答時間の発生をただ観察する以上のことができる点にあります。Perftrack はトレースの形でより多くの情報を「ダイヤルアップ」要求することができるのです。

下記の分布を考えて見ましょう。そしてシナリオは XYZ を開くこととしましょう。このシナリオで、開発チームは反応についてある目標を設定することを選びました。選択した目標に対して、緑は許容範囲内である時間を表し、黄色はぎりぎり OK とみなす時間を示し、赤は低いパフォーマンスを意味します。時間はミリ秒の単位で、X 軸に沿って表示されています。Y 軸はヒットカウントを表します。

見て取れるように、シナリオが完了するまでに 5秒以上かかっているケースが多くあります。この種の分布では、パフォーマンス チームは、過去に時間のかかる「開く」コマンドを体験したことのあるシステムからの 100 以上のトレースを「ダイヤルアップ」して要求することを推奨するでしょう。「ダイヤルアップ」 リクエストでは、私たちが興味深いと思う「閾値」の時間を設定します。加えて、ある一定量のメモリを搭載している、特定クラスのプロセッサーを搭載している、特定のドライバーが存在する、などの条件でマシンにフィルターをかけることもあります。そして、条件を満たすクライアントは、「開始」イベントに達した時点で、すばやくトレースできるように設定され、もし「停止」イベントが設定した「閾値」の時間より後に発生していれば、私たちに送り戻される可能性があります。

ご想像のとおり、相当量のエンジニアリング作業は、遠隔測定とフィードバックのシステムが機能することのために費やされます。すべてのWindows 開発チームはこのシステムを実現するために貢献しており、すでに基本的な部分は完成しているので、今後は今までほどの手間はかからないと思います。

トレースと、それによって明らかになった極めて現実的な問題の修正に重点的に取り組んだ結果、実際の反応でめざましい改善が見られ、Windows 7 に対する数々の賞賛を得ました。加えて、トレースは私たちが長い間そうだと信じてきたことを裏付けるのにも役立ったことを指摘したいと思います。

この投稿では、パフォーマンスについての私たちの考え方の概要について、そしてWindows 7 のエンジニアリングを通してそれをどう計測するかの詳細について紹介しました。ベータの期間中、私たちは目標を達成するために、よりよい遠隔測定を実行し続けようと思います。そして、Windows 7 でユーザーの皆さんに期待を上回るパフォーマンスを体感していただけると信じています。

今後も多くの人がストップウォッチやマイクロ ベンチマークを使用し続け、自動テストを実行し続けるでしょう。これらはそれぞれ、自分自身で行う分析や私たちのエンジニアリングにおいて、適した場所というものがあります。みなさんのご興味をふまえつつ、私たちがどのように物事を計測し、どのように製品を開発するかについてさらにお話することができたかと思います。

--Steven and Michael