SQL Server 64bit版は仮想メモリ拡大の恩恵を大きく受ける

Windows 64-bit Edition Technology Tourの午後は、64bit版のSQL Serverの機能概要や、具体的に32bitアプリを64bitネイティブアプリとしてコンパイルし直す場合の問題点などについて解説が行われた。

SQL Server 2000 64bit版の概要

SQL Serverについては午前中も登場したMark Franks氏が、まず既に現在製品として出荷されているSQL Server 2000の64bit版について説明を行った。同氏によれば元々SQL Server 2000の64bit版は8TBまでの仮想メモリをサポートしているほか、テーブルサイズも最大5GBと非常に巨大なデータを扱うことが可能になっているという。またメモリアドレッシングも現在のところ1TBをフラットに扱うことが可能になっているが、これは「あくまでハードウェア的な最大メモリ量が、今のところHPの64wayサーバで1TBだから1TBと言っているだけで、実際にはもっとメモリ容量が大きくてもソフト的には対応可能」(同氏)という意味なのだとか。

もちろんパフォーマンスは高く、特にメモリキャッシュが効いた場合の処理速度は非常に高速。今回は実際に5GBのテーブルを相手にSQL Queryを発行した場合の処理時間の比較を行うデモを行い、1回目は約68秒かかっていた処理が、データがメモリに読み込まれた後の2回目には同じ処理がわずか1.7秒程度で終了するところを参加者に披露した。

SQL Server 64bit版のデモ。テーブルサイズが5GBあることがわかる	64bit版でのメモリ空間

ただ現在の64bit版SQL Serverではデータ変換サービスやSQLメール、Reporting Servicesなどがサポートされていないほか、GUIの管理ツールも32bit版しか存在しないため、これを32bit環境にインストールしてリモートで64bit版のサーバを管理する必要がある。これらの問題をクリアした上に信頼性やパフォーマンスの向上、新機能の追加などが行われたのが「Yukon」(開発コード名)ことSQL Server 2005ということになるが、SQL Server 2005の64bit版は「今年夏のβ2からサポートする」(同氏)予定となっている。

SQL Server 2005の概要

64bit版ではポインタとItanium特有の問題に注意

続いて登場したマイクロソフトの長尾康氏は、C/C++で書かれた32bitアプリを64bit化するに当たってのコーディング上の問題点について解説した。

といっても、基本的に32bit版と64bit版ではAPIなどはほとんど変更がないし、また移植性を考慮して、64bit版のVisual C++でもinteger型やlong型は32bitのままとなっている。ただポインタに関してはさすがに64bit化せざるを得なかったため、例えばポインタをintやlongなどにキャストして使っているコードや、ウィンドウハンドルなどをlongにキャストしているケースなどではコンパイル時にエラーが発生したり、コンパイルは通っても実行時にメモリクラッシュが起きてしまったりするので、そのようなケースではコードの修正が必要になると同氏は説明した。

64bitアプリの開発環境	変数型の変化とAPIの変更に関する解説

また構造体などを扱う場合のメモリブロックのアライメントに関しても、32bit版では4バイトでのアライメントだったものが64bit版では8バイトのアライメントに変更されているため、この点に気をつけないとミスアライメントによってアプリケーションがクラッシュしてしうなどの可能性がある。特にItanium版ではミスアライメントが起こるとアプリケーションに例外が渡るため、アプリ側で例外をハンドリングしないとアプリの異常終了などを引き起こしてしまうことになり注意が必要だ、と同氏は述べた。

ポインタサイズ問題を解決する方法	ミスアライメントが発生した場合のプラットフォーム別の挙動

さらにItanium版特有の問題として、同氏はProfile-Guided Optimization(POGO)について解説した。これはItanium版のアプリについて、最初にコンパイルしたプログラム(Instrument Code)を実行させてプロファイル情報を収集した上で、ソースコードとこのプロファイル情報を用いて再コンパイルを行ってコードを最適化して実行速度を大幅に高速化するというもの。同氏によれば一般的にPOGO実行前と実行後では実行速度が倍くらいになる効果があるということでこれを使わない手はないが、一方でPOGOはプログラムのレイアウトを大幅に入れ替えてしまうことから、同氏は「デバッグはPOGO実行前に行っておいたほうがよい」とアドバイスしていた。

POGOの概要	POGOのフローチャート

32bit版の.NETアプリは64bit環境でネイティブ動作する?

最後に登場したマイクロソフトの佐藤直樹氏は、64bit環境下での.NETアプリケーションの開発について説明した。

もちろん.NETの32bitアプリケーションでも、午前中に解説されたWOW64を使えば基本的には問題なく動作するのは当然の話。問題は、例えば32bitで開発された.NETアプリを64bit環境下でネイティブな64bitアプリとして動作させることが可能かどうか、ということになるが、これは「条件付で可能」。同氏によれば、Visual J#のみは64bit環境下でも32bitアプリしか生成できないため、J#で書かれたアプリはWOW64上での32bit動作になってしまうというが、それ以外の言語でMSILのみで構成され検査可能なアプリケーションであれば64bitネイティブ動作が可能だという。

Windows XP＋.NET Framework 1.1上でデモアプリを実行したところ	同じアプリを64bit版で実行したところ。.NET Frameworkは2.0になっている

またVisual Studio 2005では新たにC#に「/platform」スイッチが追加され、例えばx64環境やItanium環境でのみ動作するILを生成することが可能になる。この際x64、もしくはItaniumのスイッチが指定されたバイナリは従来のPE32形式ではなく「PE32+」形式で生成されることになるとのこと。

Visual Studio .NET 2003での64bitアプリの開発について	Visual Studio 2005での64bitアプリ

.NETアプリの開発環境について

このスイッチで指定された環境はGlobal Assembly Cache(GAC)上でFusionにより管理され、例えばx64環境下でx86版とx64版で同名のアセンブリが並存することができたり、Itanium版のインストールを拒否したりできたりする。この際どちらのアセンブリが利用されるかは呼出元のアプリがどちらの環境で動いているかで決定されるため、x86版のアプリがx64版のアセンブリを呼び出したりするといったことはできないとのこと。

64bit環境でのマネージコードの挙動	同じく挙動についての解説

ただ、32bit版の.NETアプリを64bitネイティブで動作させるとなるといくつか注意が存在するという。まず浮動小数点演算については「32bitでは計算できなかったものが64bitでは計算できたりするので、両方で実行結果を同じにすることは期待せずに、IEEE-754に従った処理を行うようにすべき」(同氏)。またバイナリのシリアル化を使用する場合はポインタサイズの違いがIntPtrなどに影響してくるため、その点に注意してコードを書く必要があるとのこと。

64bit版WindowsでGACを開いたところ。中央にProcessor Architectureの項目が見える	実態はこのようにアーキテクチャ別にディレクトリが分かれている

またCOMコンポーネントを.NETアプリで利用するといった場合は、アーキテクチャをまたがった形での相互運用には困難が伴うという。今回は実際に32bit版のCOMコンポーネントをCOM+として登録することで64bitネイティブの.NET環境で問題なく動作させるといったデモも行われたが、同氏は「これはあくまでも一時的な延命策であり、こういったことはあまりやらないほうがいいのではと個人的には思う」と述べていた。