|
|
オープンソースで64 ビットコンピューティングを体験【Linux 編】 AMD Opteron の国内発表と同時に発表された「Turbolinux 8 for AMD64 」は,日本初のAMD64 プロセッサ専用OS として登場しました(写真1 ).カーネル,およびユーザ空間で動作するアプリケーション群を64 ビット化しており,AMD64 テクノロジの能力をフルに発揮できるスペックを持ちつつ,インストール手順や操作方法は従来のままとし,従来の32 ビットアプリケーションも動作可能な互換性を維持しています. 本章では,この「Turbolinux 8 for AMD64 」を実際にインストールし,AMD64 アーキテクチャと64 ビットOS との関係を調べてみたいと思います. ▼写真1 Turbolinux 8 for AMD64 ![]() ■インストール AMD64 マシンの起動画面は,従来の見慣れた BIOS 画面でスタートします.とくに特別な起動方法ではありません.また,インストーラもTurbo linux 8 workstation に採用されている「Mongoose 」を使用しているので作業手順は従来とまったく同じです.Turbolinux をPC に導入したことがあれば,とくにインストール作業で戸惑うようなことはないでしょう.製品パッケージには紙媒体のマニュアルは付属していませんが,CD- ROM にはわかりやすい「インストールガイド」が収録されていますので事前にこちらに目を通しておくと良いでしょう. Turbolinux 8 for AMD64 Update Kit Turbolinux 8 for AMD64 は,AMD 純製のチップセットでしか動作が確認されていませんでした.これは,開発当時にはAMD 純製のチップセットしか入手不可能であったためです.製品リリース後にさまざまなベンダからAMD64 対応チップセットがリリースされましたが,これらに対応するためにはカーネルのアップデートが必要となります.ターボリナックスでは「Turbolinux 8 for AMD64 Update Kit 」を提供し,これに対応しています. Update Kit を使用することにより,NVIDIA nForce3 150 やVIA K8T800 などのサードパーティ製チップセットに対応するほか,3Com 3C940 やRea lTek RTL8110/8169 などのギガビットEthernet コントローラに新たに対応します.また,MSI 製のマザーボードで発生していた割り込みが正常に取得できない問題や,Rioworks のマザーボードHDA MB にインストールできない問題,RAID モジュールaacraid を使用した際にハングアップしていた問題など既知の問題が解決されています. さらに,XFree86 も同時にアップデートされており,NVIDIA GeForce FX シリーズやVIA K8M800 などのオンボードビデオコントローラを新たにサポートしました.そのほかの詳細については,ダウンロードサイトにあるオンラインマニュアルを参照してください. Update Kit は無償で提供されているので,まずはこれをダウンロードしてください.このファイルはCD- ROM の書き込み形式であるISO9660 イメージファイルですので,CD ライタを使ってアップデートCD を作成してください.CD ライタはLinux 以外で動作するものを使用してもかまいません. インストール手順
トラブルシューティング Update Kit を使用しても,一部のマザーボードを使用した際に割り込みが正しく取得できずに周辺機器が正常動作しない場合があります.その際には,まずマザーボードメーカが提供する情報を確認し,BIOS を最新のバージョンに更新してください.また,カーネルオプションとして“noapic”を指定することによって問題を回避できる場合があるので,これも併せて試してみると良いでしょう. 場合によっては,このカーネルオプションを指定しないとインストーラさえ正常に実行できないという場合がありますので,そのときはインストーラのタイトル画面の最下段にある入力欄に“noapic ” と入力することによってカーネルオプションを設定することができます. さらに,BIOS の設定項目の中に「USB レガシーサポート」という項目があれば,これを無効にすることによって正常に起動する場合がありますのでこちらもお試しください. ■64 ビットコンピューティング インストールが完了し,システムが起動したらさっそく64 ビットのパワーを体感していきましょう.ここからは,実際に簡単なプログラムを作りながら64 ビットOS の挙動を理解していきます. AMD 64 アーキテクチャ AMD64 プロセッサには,64 ビットOS を動作させる「ロングモード」と,従来の32 ビットOS を動作させる「レガシーモード」が用意されています(表1 ). ▼表1 ロングモードとレガシーモード
AMD64 のパワーを最大限に引き出すためには,ロングモードでの実行が必要になります.さらにロングモードには,「64 ビットモード」と「互換モード」という2 つのサブモードが存在し,これらのサブモードはセグメントごとに切り替えることが可能となっています.64 ビットモードでは,AMD64 テクノロジが提供するさまざまな新機能が使用可能となり,レジスタも64 ビットに拡張されます.互換モードでは,64 ビットOS 上で32 ビットアプリケーションを動作させることが可能となるので,従来の資産を活かしつつ,必要に応じて64 ビットのパワーを活用することが可能となっています. マルチライブラリ 「Turbolinux 8 for AMD64 」をインストールすれば,ロングモードを使用した64 ビットコンピューティングが可能となります.もちろん,32 ビットでコンパイルされた既存のアプリケーションも,そのまま実行することが可能です(たとえば,Adobe Acrobat Reader などのプログラムは32 ビットプログラムですが,問題なく動作しています). それでは,OS 側では64 ビットプログラムと32 ビットプログラムを同時に実行するためにどのような工夫がなされているのでしょうか.簡単なサンプルプログラム(リスト1 )で確認してみます. ▼リスト1 サンプルプログラムhello.c
リスト1 は,C 言語の入門書でよく見かける簡単なプログラムです.これをGCC でコンパイルしてみます.
できあがったバイナリをfile コマンドで確認してみます(図1 ).単純なプログラムですが,これも立派な64 ビットプログラムであることが確認できます. ▼図1 file コマンドによる確認(64 ビット)
次に,ldd コマンドで使用しているライブラリを確認してみます(図2 ). ▼図2 ldd コマンドにより,使われているライブラリを確認(64 ビット)
“lib64 ”というディレクトリが存在し,そこに格納されている共有ライブラリにリンクされているのが確認できます.lib64 ディレクトリは,IA32 アーキテクチャやIA64 アーキテクチャでは見かけないディレクトリです. AMD64 は,32 ビットプログラムと64 ビットプログラムの両方をサポートする必要があるため,ライブラリも32 ビット用と64 ビット用の両方が提供されています.32 ビットのライブラリは従来どおりlib ディレクトリに格納され,64 ビットのライブラリはlib64 に格納されています. 共有ライブラリの格納場所を管理している ld.so.conf ファイルの中身はあらかじめリスト2 のように記述されています. ▼リスト2 ld.so.conf の内容
動的リンカは,プログラム実行時に必要なライブラリを,ld.so.conf ファイルで指定されたディレクトリから検索してロードします.64 ビットアプリケーションが実行された場合には64 ビットライブラリをロードし,32 ビットアプリケーションが実行された場合には32 ビットライブラリをロードします.これにより,32 ビットアプリケーションと64 ビットアプリケーションが同じ環境で同時に動作することが可能なのです. 続いて,リスト1 を32 ビットでコンパイルしてみましょう.それには,gcc コマンドに- m32 オプションを追加してコンパイルします.
これも同じようにfile コマンドで確認してみます(図3 ). ▼図3 file コマンドによる確認(32 ビット)
今度は実行形式が32 ビットであることが確認できます.アーキテクチャもIntel 80386 と表示されているのがわかります. 同様にldd でも確認してみます(図4 ). ▼図4 ldd コマンドにより,使われているライブラリを確認(32 ビット)
今度は lib ディレクトリに格納されている32 ビット用のライブラリにリンクされています. プログラムを作成する際に,このようなマルチライブラリ構成が問題となることがあります.とくに,Makefile でライブラリの格納ディレクトリを“/usr/lib ”に固定してしまっているような場合は注意してください.必ずmake 実行時にアーキテクチャを確認し,AMD64 の場合には/usr/lib64 をライブラリの格納場所として指定するようにしなければなりません. 変数の型 表2 はC 言語で使用されるおもな変数の型のサイズをIA32 アーキテクチャとAMD64 アーキテクチャで比較したものです.これによると,いくつかの型においてその値を格納するために確保されるメモリのサイズが拡張されていることがわかります.これらは,プログラムにどのような影響を与えるのでしょうか. ▼表2 変数の型のサイズ
●64 ビットポインタアドレス 表2 を見ると,ポインタの格納サイズが32 ビットから64 ビットに拡張されていることがわかります.これは,AMD64 アーキテクチャが提供する 4G バイトを超える64 ビットアドレス空間にアクセスするために必要となります. 従来のIA32 アーキテクチャではポインタの型が 32 ビットで表現されており,プログラム側でアクセスできるメモリセグメントのサイズは最大32 ビット=4G バイトという制限がありました.一方, AMD64 の64 ビットモードでは,理論上では64 ビット=16 エクサ(E )バイトという現在では十分に広いメモリ空間をセグメントを切り替えることなくリニアにアクセスすることが可能となっています. 注1 :実際のプロセッサでは40 ビットの物理アドレッシング(最大1T バイト)と48 ビットの仮想アドレッシング(最大256T バイト)のサポートとなっています. ときどき,無意識のうちにポインタのサイズを int とみなしてしまっているプログラムを見かけることがあります.しかし,これは64 ビットプログラムとしてコンパイルされたときに問題となりますので注意してください. 64 ビット環境でコンパイルする場合,ポインタを返す関数はすべて明示的に宣言されていなければなりません.たとえば,リスト3 のコードは非常によく見かけますが,これを正しく使用していないプログラムでは,32 ビット環境では正常に動作していても,64 ビット環境では正しく動作しない場合があります. ▼リスト3 このコードには,<stdlib.h>の読み込みが必要
コンパイラは,明示的に宣言されていない関数の返り値はint 型であると仮定します.32 ビット環境では,malloc()が返すポインタのサイズはint 型と同じ32 ビットですが,64 ビット環境ではポインタのサイズはint 型よりも長い64 ビットですので,ポインタ型とint 型の相互変換が可能であることを期待していると,ここで値が切り捨てられてしまいます.これは,ポインタ型への型キャストを記述しても回避することはできません. この問題は,適切なヘッダファイルを読み込むことによって回避することができます.malloc()が宣言されているヘッダファイルはstdlib.h ですので,これを正しく読み込むことによってmalloc() の返り値の型がポインタ型であることを明示的に宣言し,ポインタ型が暗黙的にint 型へキャストされることを回避しなければなりません. ●64 ビットメモリアクセス size_t 型が32 ビットから64 ビットに拡張されています.size_t 型は,malloc()やmemset()などを呼び出す際に,メモリサイズを指定する引数の型として使用されていますので,これにより一度に指定できるメモリサイズの上限が引き上げられることになります. ●64 ビットファイルポインタ off_t 型が32 ビットから64 ビットに拡張されています.off_t 型は,lseek()やmmap()などでオフセット位置を指定する引数の型として使用されます.一般的な32 ビットプラットフォームのLinux では,最大ファイルサイズが2G バイトに制限されています.これは,ファイル長を符号付きの32 ビット整数で管理しているためです.リスト4 は, 4G.dat という4G バイトのファイルをオープンするだけの簡単なプログラムです. ▼リスト4 サンプルプログラムfopen.c
これをAMD64 上でコンパイルし,実行してみます.
正常に処理が実行されました.では,32 ビットでコンパイルするとどうでしょう
大きなサイズのファイルを処理しきれずにエラーが発生してしまいました. 32 ビットアーキテクチャ上でも,LFS (Large File Support )が有効なシステムを使用していれば,約4T バイトまでの大きなファイルを扱うことが可能になります.64 ビットファイルへアクセスするためのインターフェースとして,fopen64(), fread64()といった関数が用意されており,マクロによって32 ビット用の関数がこれらのラージファイルアクセス用関数に置き換えられます.fopen.c の先頭にリスト5 のような2 行の定義を追加してからもう一度32 ビットでコンパイルして実行してみてください.今度はラージファイルサポートが有効となり,エラーが発生することなく正常終了したと思います. ▼リスト5 ラージファイルをサポートするために必要な記述
ただし,この方法ではfseek()やftell()といった関数を使用しているプログラムはラージファイルをサポートすることができません.これらの関数が,ファイルのオフセット値をlong int 型で扱っているためです.32 ビット環境におけるlong int 型は, LFS を有効にしても64 ビットの変数型には置き換えられませんので,あらかじめfseeko()および ftello()といったオフセット値の型としてoff_t 型を使用する関数に書き換えておく必要があります. このように,32 ビットアーキテクチャにおけるラージファイルサポートは,見かけ上うまくファイルを処理してくれますが,プログラムの一部に修正が必要となります.一方,64 ビットアーキテクチャ上では,long int 型やoff_t 型が64 ビットに拡張されているため,同じプログラムをリコンパイルするだけで64 ビットファイルを扱うことが可能となります. ●浮動小数点演算 64 ビット環境では,浮動小数点演算の処理に違いはあるのでしょうか? AMD64 アーキテクチャの浮動小数点演算は IEEE 標準に準拠しており,その仕様に従来と大きな違いはありません.互換のために従来のx87 命令を装備していますが,その性能をフルに発揮できるのは64 ビットモードで使用される拡張命令による浮動小数点演算でしょう.新たにSSE2 命令セットをサポートし,SIMD (Single Instruction ,Multiple Data:1 回の命令で複数のデータを同時に処理する方式です)による浮動小数点演算が可能なほか,128 ビット幅のXMM レジスタが8 個から16 個に拡張されます.また,long double 型が 128 ビットに拡張されており,4 倍精度の浮動小数点演算がサポートされます. ●日付と時刻 time_t 型は,time()やasctime()などの日付時刻関数で使用される型で,1970 年1 月1 日00:00:00 からの経過秒数が格納されます.32 ビットのtime_t を使用し続けた場合,「2038 年1 月19 日」で値が溢れてしまいます.これがいわゆる「2038 年問題」といわれる32 ビットアーキテクチャの限界点です.この問題は,time_t 型を64 ビット化することで解決できます.64 ビットのtime_t 型が溢れるのは何千億年も先の話ですから,当分の間は大丈夫です. ■ベンチマーク ここまで,32 ビット環境と64 ビット環境の違いを見てきましたが,ここまで読み進んだ読者なら, 32 ビットOS であるWindows XP を使ってAMD64 プロセッサのベンチマークを行うことがナンセンスであることがおわかりになるでしょう.AMD64 プロセッサを32 ビットの互換モードで動作させて Pentium 4 プロセッサと比較している文書をよく見かけますが,それでは64 ビットCPU としての AMD64 プロセッサを正しく評価しているとは言えないからです. そこで,今回はまったく同じハードウェア上で同じプログラムを32 ビットと64 ビットで動作させ,その性能の違いを測定することにします.表3 のハードウェア環境は,以降のすべてのベンチマークテストにおいて共通です. ▼表3 測定環境(ハードウェアはすべての測定で共通)
64 ビット変数の処理 リスト6 は,unsigned long long 型の変数をインクリメントしながらループさせている単純なプログラムです. ▼リスト6 loop.c
unsigned long long 型はIA32 環境でも AMD64 環境でも同じ64 ビットなので,実行結果はまったく同じです.これを64 ビットと32 ビットの両方でコンパイルしてみます.作成されたプログラムを処理するのにかかった時間をtime コマンドを使用して計測しました(図5 ). ▼図5 64 ビット変数処理に関するテストの結果
まったく同じソースコードを同じハードウェア,同じOS 上で実行したにも関わらず,32 ビット環境では約28 秒を要した処理が,64 ビット環境では約半分の約14 秒で完了しました.この結果から,64 ビット値の処理をAMD64 プロセッサがいかに効率的に行っているかということがわかります. アルゴリズムベンチマーク〜NBench NBench は,一般的な10 のアルゴリズム(表4 )を実行し,その処理時間によってシステムのCPU やメモリの処理能力を測定するベンチマークプログラムです(参考文献1 ).今回は,32 ビットと64 ビットでコンパイルされたNBench をまったく同じハードウェアとOS の上(表5 )で実行し,それぞれの結果を比較してみました. ▼表4 NBench が実行する10 のアルゴリズム
▼表5 NBench によるテストの実行環境
NBench による測定結果は,ベースラインと呼ばれる基準となる環境における測定結果との相対値で表されます.今回使用したベースラインは表6 のとおりです. ▼表6 測定結果のベースライン
測定結果を図6 に示します. ▼図6 NBench によるテストの結果 ![]() 測定結果を見ると, 64 ビット化によって処理速度が向上する物とそうでない物とがあるようです.とくに,複雑な浮動小数点演算アルゴリズムでは,64 ビットモードでの実行が32 ビットより遅くなるという結果がでました. アルゴリズムベンチマークは,同じパターンの処理を繰り返し実行してその所要時間を測定するので,コンパイラによって生成されたコードがそのアルゴリズムに対していかに最適化されているかによって結果が大きく変わる場合があります. 実際に,コンパイル時に最適化オプションの組み合わせをいくつか変更してみると,処理速度が向上するテストと低下するテストとがありました. プログラムを64 ビット化したからといって,すべてのプログラムが性能向上するわけではありません.AMD64 アーキテクチャを理解し,プログラムによってそれを適切に利用することによって,よりその能力を高めることができるのです.たとえば,ASSIGNMENT テストでは,32 ビット単位で処理を行っているので,64 ビット化しても結果はまったく変わっていません. ファイル圧縮〜gzip gzip は,広く利用されているファイル圧縮ユーティリティです.gzip コマンドの64 ビット化によって処理性能にどのような影響がでるのか確認するために,同じOS とハードウェアの上で32 ビット版と64 ビット版のgzip をビルドして,その処理速度を比較してみることにします.
を実行し,1G バイトのファイルを圧縮するまでにかかる時間を計測します. ファイルの圧縮が約2.5 倍という驚きの速さで実行されました(表7 ).これは,まさに64 ビットアーキテクチャによってファイルやメモリへのアクセスが64 ビットに拡大されたことによる効果が現れた結果と言えるでしょう. ▼表7 gzip によるテストの実行結果
レイトレーシング〜POV- Ray 次のベンチマークは,レイトレーシングソフトウェア「POV- Ray 」を使用します.レイトレーシングとは,3 次元空間の中に配置された光源の位置や物体の材質などから光の反射/屈折を計算し,リアルなCG を作り出す手法のことです.レイトレーシングを実行するためには大量の計算が必要であるため,CPU の性能測定にしばしば利用されます. POV- Ray には,標準のベンチマーク手順が用意されていますので,今回はこれを利用します(参考文献2 ).http://www.povray.org/から,標準のベンチマークで使用するbenchmark.pov ファイルとbenchmark.ini ファイルを入手し,同じディレクトリに配置します.その後コンソール上から
と実行することによって,ベンチマークテストが開始されます. プログラムを64 ビット化することで,約165 %の性能向上が確認できました(表8 ). ▼表8 POV- Ray によるテストの結果
プログラムの64 ビット化は,物理,化学などの分野における数値シミュレーションや,工業分野における高度な3 次元処理などCPU の高い演算性能を要求するシステムにおいて効果を発揮するでしょう.また, SSE/SSE2 拡張命令をサポートしていますので,これらの命令セットを使用した3D ゲームやマルチメディアアプリケーションなどにおいても性能の向上が期待できそうです. データベース〜PostgreSQL PostgreSQL は,オープンソースのデータベースシステムです.本格的なデータベースを容易に構築できることから人気があり,すでにさまざまな業務システムなどへの採用実績があります.Turbolinux 8 for AMD64 には,この64 ビットバージョンが収録されていますので,その性能を測定してみましょう.ベンチマークには,「pgbench 」を使用します. pgbench は,postgresql- contrib パッケージに収録されているPostgreSQL 用のベンチマークプログラムで,select/update/insert を含むトランザクションを実行し,1 秒間に実行できたトランザクション数を測定します.今回は,同じバージョンのPostgre SQL を32 ビットおよび64 ビットでコンパイルし,まったく同じハードウェア上にインストールして測定を行いました(表9 ). ▼表9 PostgreSQL によるテストの実行環境
データベースを64 ビット化することで,約 150 %の性能向上が見られました(図7 ).AMD64 プロセッサではメモリコントローラをCPU に内蔵することによってメモリアクセスの性能を向上させていますので,この点からもAMD64 アーキテクチャがデータベースシステムの性能向上に大きな威力を発揮することが期待されます. ▼図7 単位秒あたりの平均トランザクション数 ■まとめ すでに述べたとおりシステムの64 ビット化がすべてにおいて万能であるというわけではありません.しかし,32 ビットの限界がネックとなっているプログラムでは,それを64 ビット化することで飛躍的に性能を向上させることができるでしょう.そのためには,64 ビットアーキテクチャのしくみを正しく理解し,その能力を適切に引き出す必要があります. AMD64 の登場により,サーバだけのものであった64 ビットテクノロジがより身近になりました.すでに,さまざまなアプリケーションにおいて64 ビット化が進められています.かつて,16 ビット PC が32 ビット化されたときのように,64 ビット PC が普及するのはもう時間の問題なのです. ■メーリングリスト ターボリナックスでは,AMD64 ユーザのためのメーリングリストを開設しています. Turbolinux for AMD64 製品やAMD64 プロセッサに関する情報交換の場としてご活用ください. ■参考文献
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Copyright © Turbolinux, Inc..All Right Reserved.




