Insider's Eye 64bit時代のWindowsアプリケーション開発（3） Michael Cherry 2005/07/27 Copyright (C) 2005, Redmond Communications Inc. and Mediaselect Inc.

Microsoft製品の64bit対応状況は？

　Microsoftは64bitプロセッサの機能をより効果的に活用するため、同社のアプリケーションや開発ツールを64bit対応に書き換える作業が進んでいる。しかし、その重点はItaniumではなくx64に置かれている。さらに、既存の32bitアプリケーションの中には、64bitプロセッサで動作しないものもある。

64bitに求められる互換性と最適化

　ほとんどの32bitWindowsアプリケーションは、64bitシステムで動作する。しかし、64bitプロセッサの完全な性能を引き出すには、64bitプラットフォーム用に書き換え、最適化する必要がある。

• アプリケーションの64bitシステムへの移植および最適化［英語］（Microsoft）

■互換性を重視するx64
　基本的には、Itaniumとx64のどちらのプロセッサでも、既存の32bitアプリケーションを実行できる。中には、x64プロセッサで実行した場合、パフォーマンスが向上するものもある。

　x64プロセッサでは、パフォーマンスを損なうことなく既存の32bitサーバ・アプリケーションの大半を実行できるため、Windows Server System製品のほとんどの推奨CPUとなるだろう。

　ただし、Windowsアプリケーションの中には、どの64bitWindows OSとも互換性のないものがある。例えば、Exchange ServerはOSカーネルに32bitのデバイス・ドライバをインストールする。アプリケーションがデバイス・ドライバをインストールする最大の理由は、パフォーマンスのボトルネックを解消するためだが、このような操作をするアプリケーションとその32bitドライバは、現在の64bitCPUと64bit Windowsのプラットフォームでは実行できない。

　32bitアプリケーションをItaniumプロセッサで、WOW64サブシステムを利用して動作させた場合は、32bitシステムで動作させた場合と比べると、パフォーマンスが落ちる傾向にある。逆にx64プロセッサで動作させた場合は、若干のパフォーマンスの向上が見られるようだ。

最適化で最大のパフォーマンス

　64bit CPUが真価を発揮するには各64bitプロセッサ用に、32bitアプリケーションを書き換え、コンパイルする必要がある。

x64最適化が進む主要製品

　Windows Server System製品に一貫性を持たせることを目的としたMicrosoftのCommon Engineering Criteria for 2005では、すべてのサーバ製品を64bitに対応させ、x64用に最適化するよう規定している。現時点では、SQL ServerのみがItanium用に最適化されている。

• Common Engineering Criteria for 2005により規定されている64bitサポートの要件［英語］（Microsoft）

　主要アプリケーションの64bit対応の予定は、以下のとおりである。

■SQL Server
　SQL Server 2000は、Itanium用のWindows Server向けに最適化された64bitバージョンがすでに提供されている。2005年末までにリリースされる予定のSQL Server 2005では、Itaniumとx64のそれぞれに最適化した64bitバージョンが提供される見込みだ。

■Visual Studioおよび.NET Framework
　2005年末にリリース予定のVisual Studio 2005（VS 2005）は、Itaniumとx64のいずれのプロセッサ向けでも、64bit対応アプリケーションの開発をサポートする。これには、C#やVB.NETなど.NET Frameworkの制御下で動作する「マネージド」言語も含め、VS 2005がサポートするすべてのプログラミング言語を利用できる。現在、Visual Studio 2003でもItaniumとx64の両プロセッサ向けの64bit開発をサポートしているが、利用できる言語はC++のみである。

• .NET Frameworkの64bitサポート情報［英語］（Microsoft）

■Exchange Server
　前述のとおり、Exchange Serverの現バージョンは、32bitのカーネル・モード・デバイス・ドライバをインストールするため、64bitプロセッサでは実行できない。2006年リリース予定の次期Exchange Server（コード名：Exchange 12）では、64bit対応になり、x64向けに最適化される見込みだ。

■Windows Services for UNIX
　Windows上でUNIXアプリケーションの実行を可能にするInterixサブシステムは、32bitデバイス・ドライバをインストールするため、64bitアプリケーションとは互換性がない。これは、次期リリースで解決されると思われるが、具体的な計画は発表されていない。

■Virtual Server
　Virtual Serverは、ホストOSとゲストOSのサポートにプロセッサとの密接な連携が必要なため、Windows Server 2003の64bitエディションでは実行できない。Virtual Serverの64bit対応バージョンは、2006年にリリースされる可能性がある。

［コラム］ x64対応アプリ開発は簡単？ 64bit CPU活用のポイント 　64bitプロセッサでも既存の32bitアプリケーションを実行できるが、その性能を完全に引き出すことができるのは64bitネイティブのアプリケーションのみである。この64bitプロセッサを始め、複数のプロセッサを1つのチップまたはダイに集積する新世代のマルチコア・プロセッサの真価を引き出すには、アプリケーションの書き換えが必要になる場合がある。 　Microsoftは、32bitアプリケーションの64bitWindowsへの移植は、16bitアプリケーションから32bitWindowsへの移植に比べて容易であるとしている。最大の問題の1つは、開発者がどのようにアドレスを格納するかということだ。32bitWindowsでは、メモリ・アドレスつまりポインタのサイズと、デフォルトの整数サイズがいずれも32bitである。しかし、64bitWindowsでは、ポインタ・サイズは64bitに拡張されるが、デフォルトの整数サイズは32bitのままだ。このサイズの変更は、C言語で開発されたアプリケーションが最も影響を受けることになる。C言語では、比較的容易にポインタと整数を組み合わせて使用できるためだ。 　どの程度の作業が必要になるかを見極めるには、まず、32bitコードを64bitコンパイラでコンパイルして、その問題を洗い出す必要がある。続いて、アプリケーションが依存する共有コンポーネントをすべて特定し、16bitコードやアセンブリ・コードがないかを確認する。コードによっては、.NET Frameworkなどの別のテクノロジで置き換える必要がある可能性もある（ただし、.NET Frameworkの64bit対応は2005年後半になるもよう）。

CPUのトレンドは64bitとマルチコアへ

　Microsoftの現在のアプリケーション・ロードマップは、2006年末までにアプリケーション製品の大半をx64向けに最適化することを標ぼうしている。そのころには、実際に32bitハードウェアを購入すること自体が難しくなっているかもしれない。新しいハードウェアの大半で必要なドライバが提供されるようになり、下位互換性も維持できれば、コストをかけずに64bitシステムで32bitシステムを置き換えることができるだろう。従って、現在ハードウェアの購入を検討している場合は、将来的にデスクトップやサーバ・マシンとしての利用を視野に入れ、x64ベースのコンピュータの導入を検討することをお勧めする。

　64bitへの移行が完了した後は、さらに新しいプロセッサへの対応を考慮することになるが、これはMicrosoftにとってもユーザーにとっても64bit以上に厄介な問題になるかもしれない。特にAMDもIntelも、複数のプロセッサを1つのチップに集積する「マルチコア」デザインを採用することで、プロセッサの高速化を図ろうとしている。もともとシングル・コアおよびシングル・プロセッサ・マシン用に設計されたアプリケーションをマルチコア対応にする場合は、通常、抜本的な設計変更が必要になる。マルチ・プロセッサ・サーバ対応に必要な作業と同程度の作業が発生することになるだろう。

現在のリリース状況

　通常はx64版Windowsをプレインストールしたx64 PCをOEMから購入することになると思われるが、すでに32bitWindows XP Professionalをプレインストールしたx64 PCを発注している場合は、2005年7月31日までMicrosoftからWindows XP Professional x64の無償アップグレードを受けることができる。ただし、このアップグレード版をインストールした場合、OEMのサポートが受けられなくなる場合がある。

マルチコア対応アプリケーション開発の壁

　クロック･スピードを上げることでプロセッサのパフォーマンスを向上させるというアプローチは、技術的な限界に近づいている。クロック・スピードが向上すれば、排熱も消費電力量も比例して増加するからだ。その結果、64bitも含めて、ハイエンドのプロセッサは、複数のプロセッサを1つのチップまたはダイに集積するというマルチコア・デザインにシフトしつつある。

　32bitのWindowsアプリケーションを64bitに拡張することはそれほど難しくはないかもしれないが、マルチコアの性能を活用するには、複数のサブプログラム、つまりスレッドにうまく分割できるプログラムを開発する必要がある。これにより、複数のコアを有するマルチコアCPUが、複数のスレッドを同時に実行できるようになる。

　しかし、マルチスレッド・アプリケーションの開発は困難だ。各スレッドがプログラムに割り当てられたすべてのメモリにアクセスできるため、共有されるデータやリソースの読み取りや書き込み時に、スレッド同士が競合しないように調整する必要がある。複数のスレッドのアクティビティを同期させる方法は多数あるが、使い方を間違えるとさまざまな問題を引き起こしかねない。

問題	現象
デッドロック	あるリソースで複数のスレッドが競合した場合、デッドロックが発生する可能性がある。最も一般的なデッドロックは、2つのスレッドがそれぞれリソースを所有していて、相手が所有しているリソースを互いに待機する場合に発生するものだ。デッドロックが発生すると、一番問題がないケースだとしても、デッドロックの発生したスレッドを持つアプリケーションが停止する。最悪のケースでは、システムが応答しなくなる
競合状態	プログラムが複数の操作を同時に実行する場合に、適切に各操作を同期させなかった場合、競合状態に陥る。この場合の結果は、予測することができない。あるスレッドが共有リソースを「勝ち取る」場合もあれば、別のリソースが勝利することもある。このように動作が予想できないため、競合状態を検出し、デバッグすることは難しい

　スレッド・アプリケーションであっても、粗悪な設計のマルチスレッド・アプリケーションの場合、シングル・プロセッサ・システムでは問題なく実行できていたにもかかわらず、マルチ・プロセッサやマルチコア・システムに移植した途端に動作がおかしくなり、これまで潜んでいたデッドロックまたは競合状態が発見される場合がある。

関連リンク

• Windows Server 2003 for Itanium-based Systems（マイクロソフト）

• Windows XP Professional x64 Edition（マイクロソフト）

• Windows Server 2003 x64 Editions（マイクロソフト）

• Windows XP Service Pack 2 および Windows XP Tablet PC Edition 2005 のデータ実行防止 (DEP) 機能の詳細（マイクロソフト サポート技術情報）

• Windows Server 2003, Web Editionの概要（マイクロソフト）

• アプリケーションの64bitシステムへの移植および最適化［英語］（Microsoft）

• Common Engineering Criteria for 2005により規定されている64bitサポートの要件［英語］（Microsoft）

• .NET Frameworkの64bitサポート［英語］（Microsoft）
  

Directions on Microsoft日本語版 本記事は、（株）メディアセレクトが発行するマイクロソフト技術戦略情報誌「Directions on Microsoft日本語版」から、同社の許可を得て内容を転載したものです。『Directions on Microsoft 日本語版』は、同社のWebサイトより定期購読の申し込みができます。

　

INDEX
	Insider's Eye
	64bit時代のWindowsアプリケーション開発（1）
	64bit時代のWindowsアプリケーション開発（2）
	64bit時代のWindowsアプリケーション開発（3）

　

「Insider's Eye」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）