Windows 7 での「Windows エクスペリエンス インデックス」のエンジニアリング

世界中の Windows 7 ベータをダウンロードおよびインストールしてくださった大勢の人から山のようなレポートが寄せられ、処理に大わらわです。使い始めたみなさんの興奮がうかがえて、私たちも大変興奮しています。ベータに参加している方の多くは自分が使用しているハードウェアに精通しており調整も十分なので、Windows 7 の Windows エクスペリエンス インデックス (Windows Experience Index = WEI) や、Windows 7 で WEI がどのように変更または改良されたか、といった質問はあまり寄せられていません。この投稿では、再び Michael Fortin がWEI のエンジニアリングの詳細について語ります。 WEI は PC の主なハードウェア コンポーネントのパフォーマンスを相対的に測定するための方法で、Windows Vista から導入されました。ベンチマークのインデックスのように、相対的な評価として使用されるものであり、ある数値を他の数値と比較するものではありません。ほかの測定とは異なり、WEI は単にコンポーネントの性能を測定するものです。また、WEI は短時間しか実行されず、ソフトウェアの実行中にコンポーネントのインタラクションを測定するものではありません。どちらかと言うと、ハードウェアの特徴を計測するものです。そのため、システムが自分の使い方によってどのように動作するかは測定しませんし、測定できません。つまり、WEI はシステムのパフォーマンスを計測するのではなく、単に Windows 7 実行時のハードウェアの相対的な性能を計測するものです。 特定の個人にとって必要な 「絶対的な」 WEI を一般化しようとする方々に対して若干の注意を促したいと思います。私たちはそれぞれ PC のパフォーマンスに対して異なる許容範囲や期待を持っており、WEI の値が同じでも別の人にはまったく違った意味を持つ場合があります。私の場合、仕事の 約 9 割は WEI が 2.0 の (ゲーム用グラフィックスのコンポーネントのスコアが比較的低い) とても安いノート PC で行っています。PC では…

1

Windows 7 のエネルギー効率

この投稿では、電源管理を中心に、基本的なことを説明したいと思います。電源管理 (すなわち、エネルギー効率) は、PC エコシステムに取り組もうとする場合には必ず対応を迫られる問題であり、PC 実行時のエネルギー効率は、最もエネルギー効率の悪いコンポーネントによる制約を受けます。Windows 7 の設計時には、実行システムのエネルギー使用パターンを重視するということが明確になっており、私たちは今後も継続してハードウェアやソフトウェアの製造元と協力し、この取り組み全体を通じて得られる利点について把握するよう努めるつもりでいます。あらゆる領域におけるニーズのバランスを保とうとするときに、エネルギーの消費は、おそらく最も目に見えてわかりやすいことだと思われます。私たちが、システムを試験的に実行するときには、システムを電源メーターに接続するので、それによってテストの実行時の数値的な変化がはっきりとわかります (アポロ 13 という映画で、割り当てられている電源を有効に使おうと格闘している様子 (ずっとミッション クリティカルな問題でありますが) をご覧になった方もいらっしゃるかもしれません)。この投稿は、カーネル チームを統括するプログラム管理チームの Dean DeWhitt によるものです。 –Steven エネルギー効率は、現代のコンピューティングに関して頻繁に話題に上ることの 1 つです。その証拠に、プロセッサやチップセットのベンダーは、製品について、単なるプロセッサのクロック周波数やベンチマーク パフォーマンスではなく、"ワットあたりのパフォーマンス" を売り込んでいます。おそらく、多くのインダストリ コンソーシアムのうちの 1 つのプレス リリースで、"グリーンコンピューティング" (コンピューティングにおける電力消費と環境への影響の低減) に注目していたのをご存知の方もいらっしゃるかもしれせん。最終的に、バッテリの寿命は、常に、モバイル PC の購買とユーザビリティに影響する主要な要因となります。こうした、PC 業界におけるエネルギー効率に関する取り組みは、Windows の電源管理の方法に対する継続的な関心を呼び起こします。 Windows 7 の設計における私たちの目標は、以前のリリースよりも電力消費を削減し、ユーザーが Windows PC に望む能力と機能を提供することです。Windows では、既に豊富な省エネルギー機能が提供されています。たとえば、ユーザーがコンピューターを使用していないときには、ディスプレイの電源を切って、システムを自動的にスリープ状態にできます。Windows 7 では、こうした領域への投資を重ねており、既存の機能を拡張し、システムがアイドル状態のときの電力消費を削減することを重視しています。Windows では、プロセッサ、ハード ドライブやディスプレイなどのさまざまなデバイスの電源の状態を管理する必要がありますが、コンピューターで実行されている、それ以外のデバイスやソフトウェアも、電力消費とバッテリの寿命に関して、(それ以上とは言わずとも) 同程度の影響を及ぼします。これは、PC の操作性の向上に取り組んでいるあらゆる人々にとっての課題です。 私たちは、エネルギー効率と電力消費について話をするときに、課題となる領域を、次の 3 つに分類しています。 基本ハードウェア プラットフォーム : プロセッサ、チップセット、およびメモリ。モバイル プラットフォームの場合には、バッテリ容量も含まれます。基本ハードウェア プラットフォームは、プラットフォームの電力消費に大きな影響を及ぼす可能性があります。最大プロセッサ速度、コア数…


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

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


ディスク領域

この投稿はディスク領域と Windows 7 によって「消費される」ディスク領域についてです。ディスク領域は誰も節約したいと思っているものですが、一般的に費用対効果が大きいものでもありました。けれども、容量が回転式のドライブよりずっと小さいソリッド ステート ドライブ (SSD) の出現により、最近、状況が変わってきました。伝統的に、Windows を含むほとんどのソフトウェアは、60GB (あるいは 1,500GB) のディスクで、特定の (正当な理由の) 必要性のために 100MB を消費するのをためらうことはしませんでした。しかし、16GB の SSD を搭載したようなマシンでは、Windows が使用するディスク領域を、セットアップ時と PC 「時代」 の両方において、慎重に検討しています。WinHEC でも SSD に関する特定のセッションを提供したので、興味があればご覧ください。この投稿の著者は、コア OS 開発チームのプログラム マネージャーである Michael Beck です。 –Steven 「専有面積」 – "footprint" についてお話しましょう。この投稿の目的として、「専有面積」と言ったとき、それは Windows によって使用される物理的なディスク領域のことを意味しています。これは、Windows のバイナリ ファイルだけでなく、システムが動作するために消費または予約されるディスク領域も含みます。ディスクの専有面積がさまざまな Windows の技術によってどのように消費されるかについて、詳細に述べたいと思います。 多くのコメントの中で、ディスクの専有面積と Windows 7 のディスク使用量がどのくらいになりそうかについて尋ねられました。これまでにお話した設計に関する議題と同様、ディスク領域にもトレードオフがつきものなので、この投稿ではトレードオフのいくつかについて詳細に見ていくのと同時に、これまでに寄せられたフィードバックについてもご紹介していきたいと思います。なお、Windows 7 のシステム要件について、まだお約束できる段階ではないことにご注意願います。したがって、これは背景および技術的焦点としてお考えください。 この投稿を構成するにあたり、これまでに寄せられた 2つの重要なフィードバックおよび質問について考えたいと思います。 WinSxS ディレクトリには何が入っていて、なぜこんなに大きいのでしょうか? 削除してもかまいませんか? Windows…


フォローアップ: Windows デスクトップ検索

デスクトップ検索に関するディスカッションと電子メールは、Windows 7 のエンジニアリングに関するアーキテクチャのディスカッションを深める機会を与えてくれました。たくさんのコメントで代替の実装方法が提案されていたため、私たちは別のアプローチとそれに関するさまざまな賛否両論を話し合おうと考えました。このアプローチは、私たちが Windows 7 で苦労して実現しようとしているエンジニアリングのバランスについて示す良い例です。このフォローアップは Chris McConnell が執筆しています。–Steven (あと一週間に迫った PDC で会いましょう!) Windows デスクトップ検索に関する前回のポストにはすばらしいフィードバックをいただき、ありがとうございました。ここでは、多数出された問題点をまとめ、私たちがアーキテクチャに関して行った選択とその理由についていくつかコメントしてみました。 ファイル システムとの統合 何人かの方が指摘しているように、実装で可能な 1 つの形態として、インデックス サービスとファイル システムを統合し、ファイルが更新されたら即座にインデックスも更新されるようにするという方法があります。Windows デスクトップ検索では、これとは違うアプローチを選択しています。ファイル システムの統合には 2 つの側面があります。1 つはファイルが変更されたことの検知で、もう 1 つはファイルが「閉じ」られ、使用可能と見なされる前の実際のインデックス更新です。NTFS ファイル システムでは、ファイルが変更されると必ずインデクサーに通知されます。インデクサーは初期のインデックス作成時以外は NTFS ファイル システムをスキャンしません。私たちが統合とは異なる選択をしたのは、2 番目の点 (ファイルが閉じられるときに即座にインデックスを更新する) について考えたからです。新しいインデックスが作成されるまでその新しいファイルは検索対象になりませんが、即座にインデックスを更新するという方法によって、それが回避できるというメリットがあります。しかしこの方法には多くの潜在的なデメリットが付随します。私たちは、ほぼリアルタイムでありながらより高い柔軟性が得られるという理由により、インデックス サービスとファイル システム処理を切り離すことにしました。私たちが選んだアプローチのいくつかのメリットを次に示します。 使用されるリソースが少ないこと。システムに1 つ、グローバルなインデックスを用意しました。それは、1 つの単語とシステムの中でその単語を含むすべてのドキュメントをマッピングしています。1 つのファイルに含まれるすべての単語に対して、インデックスを作るのです。たとえば 1 つの文書であればそれに含まれる膨大な数の個別のインデックスが作成され更新されることになります。これらの変更に追従し、かつ個々のファイルと同じような堅牢さでインデックスの変更を確実に実行していくには、高いコストがかかります。インデクサーは、このような変更をスケジュールおよび集約して全体で実行される作業を大幅に減らし、CPU の使用やディスク I/O を少なくできるように設計されています。ファイルが閉じられたときにインデックス作成が発生しないことで、システムはより堅牢になります。また、必要に応じてインデックス作成をやり直すこともできます。 ファイル システム処理がインデックス サービスより優先されること。ファイルが堅牢に更新され、使用可能になっていることは、ファイルを使用するアプリケーションにとっては大前提です。ファイルを閉じる処理にインデックス作成を含めることによってファイルが使用可能になるのが遅れることは避けなければなりません。ファイルの検索は重要ですが、実際のファイル操作のほうがもっと重要です。私たちは、アプリケーションがファイル システムに関して最高のパフォーマンスを求めるために、それらが個別にインデクサーのオンまたはオフを決定する状況は望ましくないと考えています。 多くのファイル タイプを扱えること。マイクロソフトは Windows の一部として多くの共通ファイル…


Windows デスクトップ検索

多くのフィードバックのポイントの 1 つとして、サービスを無効化し必要に応じてコンポーネントをインストールする、ということがありました ― この分野での私たちの目標については、以前のポストに書きました。この種のコントロールに対する必要性の要因はさまざまありますが、キーとなる要因は、さまざまなプラットフォーム コンポーネントのパフォーマンスおよびリソース消費に関連する認識です。Windowsの目標は、開発者に対して信頼性が高く、一貫性のあるプラットフォーム ― 開発者が常にシステム サービスが提供されている場所として頼れるだけでなく、すべてのカスタマーへの恩恵につながる可能性を持つ OS の機能を当てにできる場所 ― を提供することにあります。同時に、私たちは、システム リソースの活用面で効率的な ― メリットが費用を上回るのに十分なほどの ― 方法でこれを実践する必要があります。ユーザーの何割かは手で計算する以外、この方程式の解答は得られないと信じていることも認識しています。車の性能を最大限引き出すには、マニュアル トランスミッションしかないと信じている人がいるように。このポストでは、広く利用可能なプラットフォーム コンポーネント、および豊かなエンドユーザー機能を提供するためにデスクトップ検索機能について検討するとともに、関連するエンジニアリング上のトレードオフ、およびすべてのユーザーにとってすばらしい解決策を構築するために採用している技法について説明します。このポストには Find and Organize チームのプリンシパル SDE の 1 人、Chris McConnell に協力してもらいました。– Steven ドライブのランプが激しく点滅している原因は検索インデックスの作成にあると信じていますか?友人とシューティング ゲームをプレイしているときに遅れをとる理由はこれだと信じていますか?もしこれらを本当に信じていらっしゃるのなら、今回はまさにあなたのためのポストです。Find and Organize チームは「Windows サーチ」サービスを担当しています。私たちはこれをシンプルに「インデクサー」と呼んでいます。一部の Vista パワー ユーザーからは「インデクサーを無効にして欲しい」と繰り返し聞かされています。彼らはインデクサーに PC の貴重なシステム リソースを食い尽くされているわりには、得られるものがほとんどないと信じているのです。私たちが遠隔測定した(テレメトリー)データによると、インデックス作成サービスを無効にしているのは多くても Vista ユーザーの約 1.5% です。上に書いたような認識が彼らにそうさせているのだと考えられます。 この記事はインデクサーの役割を明確化し、およびインデクサーがシステム リソースをどのように使用しているかを調査した結果について説明いたします。まず、インデックス作成サービスの機能について話すことから始めましょう。それは何のためのものでしょう?なぜそれを動作させておかなければならないのでしょうか。 インデックスの目的 今日の PC は、文書、写真、音楽、ビデオなど、さまざまな種類のファイルがあります。ユーザーが PC に保存しているファイルの数は急速に増加しています。どんなにファイルを整理しておいたとしても、欲しいものを見つけるのは日に日に難しくなっていきます。次第に、これらのファイルには、コンテンツを記述するメタデータ…


ブートのパフォーマンス

編集ノート:これは私たち開発チームのシニアメンバーによる初めての投稿になります。マイクロソフトのディスティングイッシュト・エンジニアであり、Core Operating Systemグループのファンダメンタル・チームを率いているMichael Fortinを紹介します。マイケルは、Windowsプラットフォーム全般のパフォーマンスと信頼性に関する分野を担当しています。–Steven(追伸:www.microsoft.com/ieへ行って、Internet Explorer 8のベータ2リリースをお試しください) Windows7では、スタートアップのパフォーマンスを専門に担当しているチームがあります。しかし実際にはこの活動はWindowsグループ全体さらにはそれ以上の広がりがあります。私たちと密接に協業をしていただいている多くのハードウェアおよびソフトウェア・パートナーの方々は、まさに私たちのチームの延長と考えられます。 スタートアップとは次の3種類のいずれかを指します。ブート、スリープからの復帰、そしてハイバネートからの復帰です。スリープからの復帰が最初の設定となっていて、一般的なハードウェアの上の標準のソフトウェアで多くのそのケースは2秒ないし5秒でロードされます。しかしこの投稿は主としてブートについて議論します。なぜならそれが頻繁にコメントされるからです。Windows 7での一番のゴールは、非常に良好なブート時間を得られるシステム(PC)の数を飛躍的に増やすことです。テストラボでは、非常によいシステムとは15秒未満でブートするシステムのことを言います。 PCが早くブートするには、以下のような多くのタスクが効率的に、かつ高度に並列化されて実行されることが必要です。 ファイルがメモリに読み込まれる システム・サービスが初期化される デバイスが特定され開始される ログインに必要なユーザーの資格情報が証明される デスクトップが構成され表示される スタートアップ・アプリケーションが起動される システムと構成が変わると、ブート時間は大きく変わりえます。このことは多くのラボでの検証で確認されていますが、独立した解析、たとえばEd Bottによって行われたものに見ることもできます。Edの解析したシステムのサンプル・データでは、ブートからユーザーが操作できるまでの時間が30秒以下だったのは、たった35%のシステムでした。Edのデータは比較的少ない母数からのものですが、彼の結果は私たちの解析結果とよく一致しています。Windows Vista SP1のデータ(下記)も、およそ35%のシステムが30秒以下でブートし、75%のシステムが50秒以下でブートしているのを示しています。このVista SP1のデータは、実世界での測定で得られたデータです。このデータは、Customer Experience Improvement Programを通じてユーザーがマイクロソフトに匿名で送信した、数百万という非常に多くのシステムから得られたものです。   私たちの見方では常に十分に早くブートするシステムが少なすぎであり、私たちはもっとよい仕事をしなければいけないと考えています。明らかなのは、60秒以上かかるシステムは、劇的に改善されなければいけないということです-それらの原因がデバイスの問題か、ネットワークの問題か、あるいはソフトウェアの問題であったとしてもです。ご覧になっておわかりの通り、非常に長いブート時間がかかるシステムもいくらかあります。PCの世界で私たちが観察していることのひとつはこの多様なパフォーマンスです。これは、選択肢の多様性や、個々のPCにおけるさまざまなコンポーネントの品質の多様性から来るものです。いくつかのシステム・メンテナンスのタスクも長いブート時間に寄与していることがあります。もしユーザーが大きなソフトウェアのアップデートをインストールすることを選択した場合、実際のシステムのアップデートは次回のブートの最中に起きるかもしれません。私たちのデータはこれらを捉えることもあり、残念ながらそれらは完了するのに数分かかることもあります。原因にかかわらず、PCエコシステムのメンバーである私たちがやるべき大きな仕事のひとつは長いブート時間の問題に対処することです。 Edのサンプルにおいても、我々の測定においてもブート時間とはマシンの準備ができてユーザーに反応が返ってくるまでの 時間を意味しています。これは、システムへのログイン、使用可能なデスクトップの獲得までの時間を含んでいます。これは完璧な指標ではないかもしれませんが、多くの主要な問題を浮き彫りにします。Windows 7とVistaシステムにおいてこの指標は自動的に取得されシステム イベントログに記録されます。Edのブログの記事はこれについて詳しくカバーしています。 その他にもユーザーがブート時間を示すと認識するものとして、例えばディスクが停止する時、アプリケーションが完全に立ち上がった時、もしくはスタートメニューやデスクトップが使用可能になった時、等があることを私たちは認識しています。加えて、「ブート後」時間(スタートアップグループにあるアプリケーションが実行され、遅延サービスが実行された時)、Windowsのブートが開始される前の時間、そしてBIOSが費やす時間などが重要になりえるでしょう。我々の活動では、ブート時間を考えるときにユーザーが何を重要と考えているのか、という視点を失わないようにしています。 Windows 7に対する私たちの活動についてディスカッションする前に、現在進行中のパートナーとの重要な協力関係のことを取り上げたいと思います。たくさんのシステムの調査をする中で、多くの改良が可能な箇所を発見し変更を加えました。具体的には実際のシステムから取られた以下のデータをみてください。このシステムが私達の所に届いたとき、この工場出荷時の構成ではブートに45秒程の時間がかかっていました。この同じシステムにVista SP1をクリーンインストールするとブートは23秒になりました。もちろん、クリーンインストールによってプロセスやサービスの数はずっと少なくなり、インストールされるドライバーが少し異なってきます(特にバージョンが異なります)。しかし、我々は工場出荷時の構成を最適化することによってブート時間を21秒にすることができました。クリーンインストール時よりも2秒短いもので、これはいくつかのドライバーやBIOSの変更により最適化された構成にすることができたためです。 特筆すべきはこの同じシステムに対し、スリープからのレジュームがほぼ瞬間に等しい2秒を達成したということです。我々はユーザーがスリープをブートの代替手段として選択することを強く奨励しています。 Windows 7に対する活動の例として、我々はシステムサービスに対して大きな労力を払っています。我々はシステムサービスの使用するCPU時間やディスク、メモリーの必要量の削減だけではなく、それらの数の劇的な削減を狙っています。これについての我々の考え方は単純です。もしサービスが絶対に必要なものでないのであれば、それは開始されるべきではないし、そのときだけサービスが動作するまれな条件を処理するためのトリガーが存在するはずだ、ということです。 もちろん、それがめったに発生しないもののためであろうとも、サービスは使い勝手をよくするために存在します。新しいキーボード、マウス、もしくはタブレットハードウェアのものが、システムがオフの間に追加されることを考えてみてください。もしこの新しいハードウェアが検出されず、スタートアップの際にこれらを動作させるためのドライバーがインストールされなければ、ユーザーは認証情報を入力しシステムにログインすることができないでしょう。ある種のユーザーにとってこれはめったにない、もしくはまったくない事象かもしれません。しかし、1億人のユーザーを考えた場合、これはサポートするに値するくらい頻繁に起きうる事象です。Windows 7において、さらに広範囲のサービストリガー機構が作成されたので、我々は少数の自動スタートサービスでこのシナリオと他の多くのシナリオをサポートします。 上でも書いたとおり、デバイスとドライバーの初期化も大きな一因になる可能性があります。Windows 7では、私たちはドライバーの初期化を可能な限り並列化するように注力しました。このように並列化することにより、いくつかの初期化に時間がかかるデバイスドライバーが全体の起動時間に対して影響を与える可能性を低減させることができます。 ディスクからファイルを読み込むことを考えた場合、Windows 7では“プリフェッチ”のロジックとメカニズムを向上させました。プリフェッチはWindows XPから実装されているのですが、その当時に比べてディスクの性能および特性が変化しているので、それらの変化に対応し効率的に実行できるようにスケジューリングのロジックに変更を加えました。例としては、私たちは最近のソリッドステートドライブに対してプリフェッチを、そもそも必要ないのではないかという観点も含めて評価しています。最終的には、個々のシステムで得られた解析結果により私たちがプリフェッチをどれだけ活用するかを判断いたします。 Windows 7では診断機能も改良しています。私たちは個々のシステムの特定の問題をすばやく発見し、その問題の解決の手助けを提供すべき努力しています。例えばスタートアップに登録されたアプリケーションが多すぎる場合や、いくつかのドメインに特有な時間がかかるログオンスクリプト等の問題についてユーザーに情報を提供するというようなことです。多くの皆様がご存じのとおり、スタートアップに登録されているアプリケーションが多いと、起動時間を長くする一因となります。しかし、あまり知られていないのは、問題のあるブートまたはログオンスクリプトに起因する問題についてです。Windows XP、Vista、そしてWindows 7のデフォルト動作はユーザーに時間のかかる可能性のあるネットワークの初期化またはスクリプトが実行されるのを待たずにユーザーをデスクトップにログオンさせることになっています。しかし、企業の環境下ではIT部門がクライアントシステムをネットワーク経由でサーバーと接続させるように、このデフォルトの動作を変更することが可能です。残念な事に、クライアントをこのような設定にするドメイン管理者は、しばし、これらを同期、排他的にスクリプトが実行されるように設定します。ネットワークでタイムアウトが発生したり、サーバーでの認証に問題がある場合には、結果的には、起動とログオンに数分かかってしまう場合があります。さらに、これらのスクリプトでは、CPU、ディスク、メモリのリソースを多く消費してしまうプログラムでさえも実行してしまいます。 Windows 7 のそれぞれの機能やサービスについて開発することに加えて、私たちはツール、テストデータなどをパートナーに提供しています。これらのツールは特に興味をお持ちのユーザーの方々にも提供されます。私たちが社内で起動時に発生する問題を分析・修正するために使っているこれらのツールは、Windows Performance Toolkitとしてこちらからダウンロードすることができます。これは一般的なユーザーが使うためのものではありませんが、一部の方々には非常に有益なものです。 これからお話したいことのトピックの一つはすでに多く書かれていますし、たくさんのコメントの主題にもなっています。それは、Windowsに追加されたソフトウェアが全体的なシステムパフォーマンスにどう影響を及ぼすか、ということです。本当に広く深い用途のWindows用ソフトウェアというものは、ある特定の人だけが満足するような品質であればよいというものではなく、圧倒的多数の人たちが非常によいと思うようなものです。マイクロソフトは高いパフォーマンスのソフトウェアを開発するためのツールや、期待通りのパフォーマンスで動いていないソフトウェアを特定するツールを、提供し続けなければなりません。Windows それ自体では、パフォーマンス低下の原因になりそうなソフトウェアを検出しユーザーに知らせたりする、という防御的手法をさらに改善していかねばなりません。…


Windows 7 – システム パフォーマンスへの取り組み

たくさんの皆さんからWindowsのパフォーマンスについてのコメントやemailをいただきました。それらは、かなり幅広いものですが、中でもパフォーマンスの向上について(当然ながら)多くの要求がありました。パフォーマンスと言うと絶対で簡単に計測可能に感じますが、これからここで議論しようと思っている様々なトピックと同様に多くの側面があります。全ての皆様のご期待に応えられるようなパフォーマンスを実現しようとすると、パフォーマンスにも様々な要素が存在し様々なトレードオフが存在していることがわかります。もちろん、仮に期待値を達成できたとしても、皆様はさらなるご期待をWindows PCに対して持たれることでしょう(これもまた当然なことです)。私たちはWindows 7(とIE8)においてはこの分野に改めて注力しています。これは各フィーチャーチームにおいての重要なイニシアチブですし、数あるフィーチャーチームの一つであるFundamentalチームの主要なミッションになっています。この記事では、この議論の枠組みだけをお話しさせていただきパフォーマンスのお話は今後の記事で詳細に書いていきたいと思っております。IE8 performanceのBlogの記事とIE8のベータ2 リリース等がこの件に関連している項目ですので参考にしてください。 パフォーマンスはたくさんの要素によって構成されています。時には、特定のリクエストに対する反応時間について語られている場合があります。また、それは“一般的に”どのぐらいRAMが必要か、どのCPUが必要かという事かもしれません。あるいは、プログラムを起動するまでに必要なクロック数のことかもしれません。CPU使用率、disk I/O 活動の多さ(または少なさ。)等を監視することを意味するかもしれませし、バッテリ寿命のことかもしれません。ひょっとしたら、インストール後のハードディスク上のサイズというようなありふれたことなのかもしれません。これらはすべてパフォーマンス測定する上での要素です。これらはすべて開発時にはシステマチックに管理されています。いくつかの既知のシナリオ(何千とあります。)で私たちはパフォーマンスを計測しており、開発者は特定のシナリオを深く広く実行し検証しています。以下にWindows 7の開発において計測しているいくつかの指標(全体の一部ですが)を紹介します。 メモリー使用率‐特定のシナリオを実行する上でどれだけのメモリーを振り当てるか。ご存知かとは思いますが、コンピューターサイエンスにおいては時間対空間の古典的なトレードオフが存在しており、私たちは決して例外ではありません。このトレードオフをキャシュ関連で、たとえばさらに多くのメモリ(またはディスク容量)を使う事によってパフォーマンスの向上または再計算を避ける事ができます。 CPU 使用率 – 明らかに、モダンなマイクロプロセッサは莫大なプロセッシングパワーを提供しており、また、マルチコアの出現により並列化の機会がますます増えております。もちろん、これらのリソースで実現可能なことは無限ではないので、CPU使用率を図るベンチマークを実行しています。一般的には、ゴールはこれらをできる限り低くすることです、なぜならば、そうすることによりマルチユーザーのシナリオを改善し電力消費量を抑える事が出来るからです。 ディスク I/O - ハードディスクの性能が格段に進歩したとはいえ、我々はできる限りWindowsそのものが行うディスクへの読み書きを少なくしなければなりません。(もちろん、ページングも含めてです。)この分野はソリッドステートストレージという従来とは違った“特性”を持ったデバイスの出現によりWindows 7では特に注意しています。 起動、シャットダウン、スタンバイ/レジューム‐ これらはすべてWindows 7で注力している点です。これらのものが“充分、速い”という状況にはならないと考えています。これらのトピックに関しては実験室で得られる結果(または“クリーンインストール”時のパフォーマンス)が新しく買ってきたPCにも反映されることが重要であり、それにはメーカー様やハードウェアメーカ-様とのコラボレーションがきわめて重要な役割を担っております。 ベースシステム – 基礎となるシステムでの計測、チューンに我々はかなりの時間をかけています。これは追加のソフトウェアがロードされる前の状態でのリソース利用率を指しています。このシステムがすべてのデベロッパーが期待できるシステムを定義付け、一般的なエクスペリエンスを体験できるシステム要求を定義づける、“土台”となります。良くあるリクエストとしてはベースシステムから除外して、“オンデマンド”で利用するというリクエストです。これのトレードオフは、我々が頻繁に作業する項目です。しかし、注意して避けなければいけないのは、大半のお客様がこの何かしらの“オンデマンド”でのロードに直面し、一般的なシナリオで実感としてのパフォーマンスが低下する事です。 必要ディスク容量 – 直接的には実行時のパフォーマンスには影響はしないのですが、多くの人がOSの容量を実感としてのパフォーマンスを暗示するものと考えています。私たちはこの問題に対しても特定のゴールを設けており、今後詳細について書きたいと思います。また、\Windows\WinSxSについても説明していきたいと思います。なぜなら、これはtechnetやmsdnでしばし議論の対象になっているからです!ここでは実行時のトレードオフではなく、例えば、ハードディスク上のデバイスドライバ、アシスタンス用のコンテンツ、オプショナルなWindowsのコンポーネントや診断ツール、ログ情報があるのですが、これらには便利さとのトレードオフが存在しています。 私たちは開発の節目ごとに次のステップに進むかどうかの判断基準を設けており、その基準が満たされることなしに出荷をすることはありません。ある時には、これらの基準はマイクロベンチマーク(ページフォールト、CPU使用率、ワーキングセット、画面のフレームレートなど)のことを意味し、またある時は、ユーザーシナリオに即したものでありひとつのタスクを完了するための時間(時計時間、マウスクリック数)を意味します。私たちは、いろいろなハードウェアプラットホームでこれらの測定をします(32ビット/64ビット; 1, 2, 4GBのRAM; 5400~7200の回転数を持つハードディスクまたはソリッドステートディスク、いろいろなプロセッサー、その他)。設計上の都合により以前からあるものとトレードオフ関係がある場合は、Windows が動作しているハードウェアのタイプによって条件分けをするプログラミングを加えることもあります。 一方、パフォーマンスに関する議論はシンプルでなければなりません。機能が少なくなればパフォーマンスは向上するはずです。極端な場合では、それは顕著に表れます。しかし、いただいた多くのコメントには、一人の人にとっては必要なある機能が、別の人にとってはまったく必要ない機能ということもあります。これは“見た目に派手な機能”について特によく聞くことです – ユーザーインターフェースをアニメーションやグラフィックスなどを使い(“私たちの競合相手の製品のような”)もっと楽しいものにしてほしいというたくさんのリクエストをいただく一方で、 “グラフィックスなど使わずにWindows 2000に戻してくれ”、というご意見もあります。Windowsは非常に柔軟で、ユーザーの使い方に合わせるための多くの方法を提供しています。様々なお客様のために違った種類のWindows をリリースすることについてのご意見をいただきました。その一方で、 Windowsのバージョンの数を減らすべきだというかなりの数のご意見も頂戴しました。しかし、私たちが提供できることには限度があり、また、お客様や開発者から信頼していただくに足りうる、多くのお客様にとって頑丈で管理しやすい“プラットフォーム”を提供することにも限度があります。しかし、もちろん既知の前後関係(すでにあるソフトウェアが稼働している、ご家庭の中、または企業の中で)の範囲内で、Windowsが持っている様々なカスタマイズや管理方法を利用することは常に可能です。カスタマイズの選択の余地があることそしていったい何がお使いのPCで発生しているのかをコントロールすることは、私たちにとって最も重要であり、私たちはWindows 7でもこれらの側面に引き続き注力します。 お客様に今後もPCを使い続けていただき、PCでさらにたくさんのことを正しく行い、たくさんのソフトウェアがPC 上で期待通りに動くこと。これはパフォーマンスと関連してよりよいPCの使い勝手を実現するための私たちの最も大きい挑戦です。今後もWindowsの機能は増えていくことになると思いますが、私たちはより多くのお客様に対する利便性が高まると考えられる機能を厳選していきます。同時に、Windows 7のかなりの部分は、ソフトウェアとしてWindowsに起こることやデフォルトハンドラーがファイルタイプやプロトコルに対してどのように作用するかということなどに対し、選択とコントロールを提供し続けることになるでしょう。また、エンドユーザーに対してコンピューターの使い勝手をよくするためのプラットフォームとしての機能をサポートし続けます。 現実と理想のバランスについては、深く考慮する必要があります。Windowsを開発するにあたり、私たちは追加したコードがどのようなインパクトがあるかどうか確認するために実験室の中でベンチマークテストを行います。私たちもPCが出荷された後、PCメーカーと緊密にコラボレーションを行い、彼らのシステムをベンチマークでテストすることをお手伝いします。そして、Microsoft Customer Experience Improvement Programは、私たちにPCがどのように稼働しているかという(匿名で個人的かつ選択的な)データを、現実の世の中でのパフォーマンスデータとして提供します。逸話や信頼できない形の情報を使用するよりは、現実はどうなっているのかを議論するベースになるものとして、私たちはこれから数カ月にわたりそのデータを利用していきます。 次のポストでは起動時のパフォーマンスを取り上げます。多くの皆様の関心をいただき、私たちはパフォーマンスの話題についてたくさんのことをお話しなければなりません。 –Steven