HPC/並列プログラミングポータルでは、HPC(High Performance Computing)プログラミングや並列プログラミングに関する情報を集積・発信しています。 |
[記事一覧を見る]
インテル コンパイラーにはさまざまな最適化機能が備えられており、そのためインテル コンパイラーでコンパイルしたプログラムは高速に動作すると言われている。しかし、そのためだけにわざわざソースコードからコンパイルを行うのは面倒だ、という人も多いだろう。そこでSourceForge.JP Magazine編集部では、インテル コンパイラーでコンパイルされたソフトウェアをより多くの人に試してもらうため、「インテル コンパイラー 1000本ノックプロジェクト」と題し、インテル コンパイラーでコンパイルしたプログラムを公開することにした。
インテル コンパイラーには自動並列化や自動ベクトル化、プロシージャ間の最適化(Inter Procedural Optimization、IPO)など、高速に動作するバイナリコードを生成するための機構が備えられている。これによって、Visual C++やGCCなどでコンパイルしていたアプリケーションを、インテル コンパイラーを使用して再コンパイルするだけでパフォーマンスが向上する可能性がある。
しかし、ソフトウェアによっては特別な設定が必要だったり、ソースコードの修正が必要な場合もある。そこで、気軽にインテル コンパイラーで作成したプログラムを試せるように、また自分でコンパイルを行う際にその手順が具体的に分かるように、インテル コンパイラー 1000本ノックプロジェクトではインテル コンパイラーで作成したプログラムの配布や、コンパイル方法の解説を行っている。
本記事ではこのプロジェクトで扱っているいくつかのオープンソースソフトウェアについて、そのコンパイル手順を紹介するほか、パフォーマンスの調査も行っているので、ぜひ参考にしてほしい。
インテル コンパイラーはVisual C++やGCCといったコンパイラと高い互換性を備えている。たとえば、Windows版のインテル コンパイラーはVisual C++と、Linux/Mac OS X版はGCCとコンパイルオプションの互換性があり、Visual C++やGCC向けのコンパイルオプションをそのまま認識する。Windows版のインテル コンパイラーにはVisual Studioの統合開発環境(IDE)用プラグインも含まれており、Visual StudioのIDEを利用するプロジェクトであれば、非常に簡単にインテル コンパイラーで再コンパイルできる。また、コンパイルにmakeや専用ビルドスクリプトなどを使用しているソフトウェアの場合でも、多くの場合コンパイラとしてインテル コンパイラーを使用するよう設定するだけで問題なくコンパイルが可能だ。
とはいえ、いくつか注意が必要な点もある。インテル コンパイラーはVisual C++やGCCと互換性があるといえども、100%同一、というわけではない。Visual C++やGCCでしか利用できない機能や若干仕様が異なる部分もあるため、ソフトウェアによってはソースコードの修正等が必要になる場合がある。そこで、まずはインテル コンパイラーで既存のソフトウェアをコンパイルする際の注意点や、知っておくと役立つ事項を紹介しておこう。
Windows向けのソフトウェアの場合、Visual StudioのIDEを使用してコンパイルを行うことが多いだろう。この場合、インテル コンパイラーに含まれるVisual Studio IDEプラグインを導入することで、簡単にインテル コンパイラーを使用するよう設定できる。
Visual Studio IDEプラグインをインストールすると、Visual StudioのIDEに図1のようなツールバーが追加されるほか、ソリューション エクスプローラ画面のショートカットメニューに「インテル(R) C++ コンパイラー・プロフェッショナル」という項目が追加される(図2)。インテル コンパイラーを使用したいプロジェクトをソリューション エクスプローラで選択し、ツールバーの「インテル(R) C++を使用」ボタンをクリックする、もしくはショートカットメニューの「インテル(R) C++ コンパイラー・プロフェッショナル」の「インテル(R) C++を使用」メニューを選択すると、ソリューション エクスプローラのプロジェクトアイコンが「C++」というものに変わり、インテル コンパイラーが使用されるようになる仕組みだ(図3)。
また、「ビルド・コンポーネントの選択」メニューでは、インテル コンパイラーに付属するインテル インテグレーテッド・パフォーマンス・プリミティブ(IPP)やインテル マス・カーネル・ライブラリー(MKL)、インテル スレッディング・ビルディング・ブロック(TBB)の使用の有無などについても設定できる(図4)。
makeやビルドスクリプトを利用してコンパイルを行う場合に押さえておきたいのが、インテル コンパイラーに含まれるコマンドラインツールとその名称だ(表1、2)。インテル コンパイラーにはコマンドラインツールとしてC/C++コンパイラと専用のリンカー、ライブラリ/アーカイブ管理ツール(アーカイバ)が含まれている。たとえばWindows版のC/C++コンパイラは「icl.exe」、Linux/Mac OS X版のC/C++コンパイラは「icc」という名称となる。
ツール | Windows版コマンド名 | 対応するVisual C++付属ツール |
---|---|---|
C/C++コンパイラ | icl.exe | cl.exe |
リンカー | xlink.exe | link.exe |
ライブラリ/アーカイブ管理ツール(アーカイバ) | xilib.exe | lib.exe |
ツール | Linux/Mac OS X版コマンド名 | 対応するbinutilsツール |
---|---|---|
Cコンパイラ | icc | gcc |
C++コンパイラ | icpc | g++ |
リンカー | xild | ld |
ライブラリ/アーカイブ管理ツール(アーカイバ) | xiar | ar |
また、インテル コンパイラーでプロシージャ間の最適化機能を有効にしてコンパイルしたオブジェクトファイル(「/Qipo」もしくは「-ipo」オプションを付けてコンパイルしたオブジェクトファイル)は、Visual C++やGNU binutilsに含まれるリンカーやライブラリ/アーカイブ管理ツールでは扱えない。これらのオブジェクトファイルをリンクしたり、ライブラリ化する場合は、インテル コンパイラーに付属するxlink.exeやxild、xilib.exe、xiarといったツールを用いる必要がある。
makeやビルドスクリプトを用いてプログラムをコンパイルする場合は、これらのツールを使用するようMakefileやスクリプト、環境変数などを変更すれば良い。たとえばLinux環境でconfigureスクリプトを使ってコンパイルする場合は、次のようにCCおよびCXX、LD、ARという環境変数を指定してconfigureを実行すれば良い。
./configure CC=icc CXX=icpc LD=xild AR=xiar
インテル コンパイラーはVisual C++やGCCとの互換性があるものの、微妙に仕様が異なる点もある。互換性に関する情報は、インテル コンパイラーのオンラインヘルプ内「Microsoftとの互換性」および「gccとの互換性」ページに詳細が掲載されているが、インテル コンパイラーではVisual C++およびGCC独自の言語拡張やキーワードの一部をサポートしていないほか、標準ではより厳密な型チェックなどが行われる。そのため、Visual C++やGCCで問題なくコンパイルできるソースコードであっても、インテル コンパイラーでコンパイルするとエラーや警告(Warnings)が発生する場合がある。このような場合、インテル コンパイラーに用意されている互換性保持のためのコンパイルオプションを使用することで問題を解決できることがある。
Windows版インテル コンパイラーには、「/Qms0」および「/Qms1」、「/Qms2」という「Microsoft互換性オプション」が用意されている(表3)。これらはC/C++標準規格に沿っていないVisual C++の挙動やバグ等をエミュレートするものだ。また、Visual Studio .NET 2003/2005/2008との互換性を保つためのオプションも用意されている。
オプション | 意味 |
---|---|
/Qms0 | C/C++標準規格に準拠する範囲内でVisual C++をエミュレートする |
/Qms1 | /Qms0より多くのバグ/仕様をエミュレートする |
/Qms2 | Visual C++の仕様を最大限エミュレートする |
/Qvc7.1 | Microsoft Visual Studio .NET 2003との互換性を保つ |
/Qvc8 | Microsoft Visual Studio .2005との互換性を保つ |
/Qvc9 | Microsoft Visual Studio .2008との互換性を保つ |
また、Linux/Mac OS X版インテル コンパイラーでは、コンパイラの動作をGCCの特定バージョン互換にするオプションが用意されている(表4)。さらに、Linux/Mac OS X版インテル コンパイラーは独自のC++ライブラリを使用するが、「-cxxlib」オプションを指定することで、GCCに含まれているC++ライブラリやヘッダーファイルを使用してコンパイルを行うことが可能だ。
オプション | 意味 |
---|---|
-gcc-version=<バージョン> | 指定したGCCバージョンとの互換性を保つ |
-cxxlib | GCCに含まれるC++ライブラリおよびヘッダーファイルを使用する |
以上ではインテル コンパイラーを使用する際の基本的なポイントを紹介したが、もちろんソフトウェアによってはコンパイルのために上記以外の修正が必要な場合がある。そこで例として、「インテル コンパイラー 1000本ノックプロジェクト」で取り上げているオープンソースソフトウェアのいくつかについて、具体的なコンパイル例を紹介しておこう。
2009年9月末時点で公開しているソフトウェアは、次の表5のとおりだ。また、このうちのいくつかについてはコンパイル方法やパフォーマンス比較も行っている。ここではLAMEや7-Zip、Audacity、x264といったソフトウェアについて触れているが、ここで挙げたソフトウェア以外についても随時追加・更新を行っているので、プロジェクトページの情報もチェックしていただきたい。
ソフトウェア名 | 説明 | 対応OS | 解説 |
---|---|---|---|
LAME | MP3エンコーダ | Windows、Linux | コンパイル方法、パフォーマンス比較 |
7-Zip | ファイル圧縮/展開ツール | Windows | コンパイル方法、パフォーマンス比較 |
Audacity | Windows | 音声波形編集ソフト | コンパイル方法 |
x264 | H.264エンコーダ | Windows、Linux | コンパイル方法、パフォーマンス比較 |
FAAC | AACエンコーダ | Windows | コンパイル方法、パフォーマンス比較 |
OpenSSH | SSHクライアント | Linux | コンパイル方法、パフォーマンス比較 |
bzip2 | ファイル圧縮/展開ツール | Linux | コンパイル方法、パフォーマンス比較 |
ImageMagick | 画像ファイル処理ツール | Windows | コンパイル方法、パフォーマンス比較 |
Firefox | Webブラウザ | Windows | コンパイル方法、パフォーマンス比較 |
MySQL | データベースシステム | Linux | コンパイル方法、パフォーマンス比較 |
なお、特に言及がない場合、本記事内でのパフォーマンス検証には次の表6の環境を用いている。
スペック | Windowsでの検証環境 | Linuxでの検証環境 |
---|---|---|
OS | Windows Vista Business SP2 | Debian GNU/Linux 5.0 |
CPU | Core 2 Duo E6550(2.33GHz) | Core i7 920(2.66GHz) |
メモリ | 2GB | 3GB |
コンパイラ | インテル コンパイラー 11.1、Visual Studio 2008 | インテル コンパイラー 11.1、GCC 4.3.2 |
「LAME」は、オープンソースのMP3エンコーダだ。GPL/LGPLで提供されており、高品質なエンコードが行えると言われている。LAMEは元々MP3のエンコードを行うライブラリ+コマンドラインフロントエンド、という構成だったが、現在ではさまざまなエンコードツールなどでMP3エンコーダとして採用されている。
LAMEのソースコードはダウンロードページから入手が可能だ。ここでは2008年9月23日公開のlame 3.98.2を使用した。lame 3.98.2の配布アーカイブ(lame-398-2.tar.gz)にはUNIX/Linux環境でコンパイルを行うためのconfigureスクリプトのほか、Visual Studio向けのプロジェクトファイルや、Mac OS Xの開発環境であるXcode向けのプロジェクトファイルなども含まれている。
Windows環境でインテル コンパイラーを用いてLAMEをコンパイルするには、このプロジェクトファイルを利用するのが簡単だ。まず、使用しているVisual Studioのバージョンに対応するVisual Studioのプロジェクトファイルを開く(たとえばVisual Studio 2005/2008の場合は「lame_vc8.sln」)。続いてソリューション エクスプローラで「ソリューション 'lame_vc8'」を選択し、ツールバーもしくはショートカットメニューの「インテル(R)C++を使用」をクリックする。あとはプロジェクトのプロパティでコンパイルオプション等を設定し、「ソリューションのリビルド」を実行するだけだ。
またLinux環境では、次のようにコンパイラやリンカー、ライブラリ/アーカイブ管理ツールを指定してconfigureスクリプトを実行した後、makeコマンドおよびmake installコマンドを実行すれば良い。なお、コンパイルオプションは「CFLAGS」で指定できる。
$ ./configure CC=icc CFLAGS="-O3 -ipo" LD=xild AR=xiar $ make $ sudo make install
パフォーマンスの検証には、先述のLAMEのコマンドラインフロントエンド(lameコマンド)を使用した。約3分30秒のWAVE形式ファイルをデフォルト設定でMP3にエンコードし、かかった時間を測定・比較した。
なお、LAMEのソースコードにはアセンブラで記述されたコードも含まれており、コンパイル時の設定でアセンブラ版のコードを使用するかどうかを選択できる。そのため、ここではアセンブラを利用する場合と利用しない場合についてもそれぞれ性能比較を行っている。
さて、実行結果であるが、表7、8のとおりとなった。Windows版、Linux/Mac版ともにインテル コンパイラーを使用することで1割以上のパフォーマンス向上が見られている。
コンパイラ/コンパイルオプション | エンコード時間 |
---|---|
Visual C++(/O2) | 13.083秒 |
Visual C++(/O2)+アセンブラ | 10.992秒 |
インテル コンパイラー(/Ox、/Qipo) | 9.740秒 |
インテル コンパイラー(/Ox、/Qipo)+アセンブラ | 8.692秒 |
コンパイラ/コンパイルオプション | エンコード時間 |
---|---|
GCC(-O2) | 8.610秒 |
GCC(-O2)+アセンブラ | 7.216秒 |
インテル コンパイラー(-O3、-ipo) | 7.348秒 |
インテル コンパイラー(-O3、-ipo)+アセンブラ | 5.750秒 |
7-Zipは7z形式やZIP、GZIP、BZIP2、TAR形式の圧縮/展開に対応したWindows向けアーカイバだ。そのほか、ARJやCAB、LZH、RARといったファイルの展開にも対応しており、Windows環境では人気の高いアーカイバツールの1つである。
7-Zipのソースコードは、ダウンロードページから入手できる。記事執筆に使用したのは、2009年2月3日公開の7-Zip 4.65だ。
7-ZipのコンパイルではVisual StudioのIDEを利用せず、コマンドプロンプトからVisual Studio付属のnmake.exeを使用してコンパイルを行う。使用するコンパイラやコンパイルオプションといった設定については、7-Zipのソースコードアーカイブ(7z465.tar.bz2)を展開すると作成される「CPP」ディレクトリ内にある「Build.mak」に記述されている。このファイルを編集する、もしくはこのファイル内で参照されている「CPP」および「CFLAGS」環境変数を設定することでコンパイルオプション等を変更できる。
たとえばコンパイラとしてインテル コンパイラーを使用する場合、次のようにCPP環境変数に「icl」を設定すれば良い。
set CPP=icl
また、コンパイルオプションについては同様にCFLAGS環境変数を設定する。
set CFLAGS=<設定するコンパイルオプション>
なお、デフォルトの設定ではコンパイルするモジュールによって、最適化オプションとして「/O1」(コードサイズの最小化)と「/O2」(実行速度の最適化)を使い分けるようになっている。これらも変更したい場合は、Build.mkファイル中で「CFLAGS_O1」および「CFLAGS_O2」の設定を行っている下記の個所にある「-O1」および「-O2」を書き換えれば良い。
CFLAGS_O1 = $(CFLAGS) -O1 CFLAGS_O2 = $(CFLAGS) -O2
以上のように環境変数およびBuild.mkファイルを設定後、「CPP\7zip」ディレクトリ内でnmake.exeを実行するとコンパイルが行われる。
なお筆者が試したところ、コンパイルの際にCPP\7zip\UI\FileManager\Panel.hの459行目でコンパイルエラーが発生した。これは、該当の行を次のようにコメントアウトすることで回避できる。
// CDisableTimerProcessing operator=(const CDisableTimerProcessing ) {; }
また、7-Zipのデフォルトコンパイル設定では、警告をエラーとして扱うようになっている。そのため、デフォルトで発生する「セキュアでないCランタイム関数を使用している」という旨の警告がコンパイルエラーとして扱われてしまう。この警告については、コンパイルオプションとして「/D_CRT_SECURE_NO_WARNINGS」オプションを付けることで抑制できる。
set CFLAGS=/D_CRT_SECURE_NO_WARNINGS
コンパイルが完了すると、CPP\7zip\Bundles\ディレクトリおよびCPP\7zip\UI\ディレクトリ以下にEXEファイルおよびDLLファイルが作成される。ここで出力されたEXEファイルおよびDLLファイルには、使用するDLLに関する情報(マニフェスト)が含まれていないため、そのままでは実行時にエラーが発生する。マニフェストをEXEファイルおよびDLLファイルに埋め込むには、各EXEファイル/DLLファイルが生成されているディレクトリで次のように実行すれば良い。
mt.exe /manifest <EXEファイル名もしくはDLLファイル名>.manifest -outputresource:<EXEファイル名もしくはDLLファイル名>
コンパイルオプションについては変更せず、単純に使用するコンパイラのみを変更してパフォーマンスの違いを測定した。測定条件は下記の4つである。
測定結果は次の表9のようになった。7-Zipでは最適化オプションとして「/O1」が多用されていることもあり、単純にインテル コンパイラーを使用するだけでは明確なフォーマンス向上は見られないようだ。使用するコンパイルオプションをもう少し吟味する必要があると思われる。
条件 | コンパイラ | かかった時間 |
---|---|---|
大きなファイル(ZIP) | インテル コンパイラー | 10.14秒 |
Visual C++ | 10.88秒 | |
大きなファイル(7z) | インテル コンパイラー | 38.135秒 |
Visual C++ | 37.882秒 | |
多数のファイル(ZIP) | インテル コンパイラー | 2.787秒 |
Visual C++ | 2.761秒 | |
多数のファイル(7z) | インテル コンパイラー | 6.958秒 |
Visual C++ | 6.796秒 |
「Audacity」はオープンソースで開発されている波形編集ソフトで、Windows/Mac OS X/Linuxで動作する。
Windows環境でのコンパイルについては別途wxWidgetsライブラリが必要であり、若干手順が複雑である。ただし、基本的にはAudacity公式Webサイトにある解説、およびソースコード中の「Win」フォルダ内にある「compile.txt」の指示に従えば良い。また、Audacityのダウンロードページ内で配布されているソースアーカイブには一部の依存ライブラリのソースコードが含まれていないため、そちらではなくCVSを用いてソースコードを入手する点に注意してほしい。
CVSで取得したソースコード中にはVisual Studioのプロジェクトファイルが含まれているので、インテル コンパイラーでコンパイルするにはこれをVisual Studioで開き、LAMEの場合と同様にIDEからインテル コンパイラーを用いるように設定すれば良い。
x264は、GPLで提供されているH.264エンコーダだ。WindowsやMac OS X、Linux/UNIXで動作し、またエンコーダエンジンとしてさまざまなアプリケーションで利用されている。
x264の公式サイトではソースコードの開発版スナップショットのみが配布されており、x264のWindows向けバイナリはhttp://x264.nl/にて配布されている。また、Gitによるソースコードの取得も可能だ。
x264の配布ソースコードには、「build\win32」ディレクトリ以下にVisual Studioのプロジェクトファイルが含まれている。こちらをVisual StudioのIDEで開き、コンパイル設定を行えば良い。
なお、筆者が試したバージョンのソースコードでは、「C99」と呼ばれる、1999年に策定されたCの新標準規格内で採用された機能が用いられている。そのため、C99に対応していないVisual C++ではそのままではコンパイルできなかった。インテル コンパイラーでは、「/Qstd=c99」オプションを使用することでC99サポートを有効にでき、問題なくコンパイルが可能である。
また、x264ではSSE2を利用するためのアセンブラで書かれたコードが含まれているのだが、このコードはGCC向けに記述されており、そのままではインテル コンパイラーで利用できない。そのため、Visual C++やインテル コンパイラーでコンパイルしたバイナリは、GCCでコンパイルしたバイナリよりもパフォーマンスが低下してしまう問題がある。
そのほか、コンパイルを行うために加えた修正点は以下のとおりだ。
Linux環境でのx264のコンパイルでは、configureスクリプトを使用してコンパイル設定を行っている。そのため、次のようにconfigureを実行するだけでコンパイルが可能だ。
$ CC=icc CFLAGS="<コンパイルオプション>" ./configure
パフォーマンス比較には解像度720×480、約7秒の動画ファイルを用い、このファイルをデフォルト設定でエンコードした場合のフレームレートを比較した。結果は下記の表10のとおりだ。また、コンパイルオプションについてはデフォルトのものを用いている。結果を見ると、インテル コンパイラーで作成したx264のほうが、若干ではあるがフレームレートが高くなっている。
コンパイラ | 平均フレームレート |
---|---|
インテル コンパイラー | 63.58fps |
GCC | 61.98fps |
現在よく使われている音声圧縮コーデックの1つに「AAC」がある。AACは地上デジタル放送や、アップルのiTunesのデフォルトコーデックとして採用されているコーデックで、低いビットレートでも比較的高音質なのが特徴だ。AAC形式での音声圧縮を行うAACエンコーダはいくつか存在するが、オープンソースで提供されているものとして「FAAC」がある。
FAACはコマンドラインツールおよびライブラリとして提供されているが、オープンソースで提供されているためほかの動画/音声エンコーダツールなどでも多く採用されている。
FAACのソースコードは、ダウンロードページから入手可能だ。本記事では、2009年2月11日に公開された「faac-1.28.zip」を使用した。このソースアーカイブを展開すると、「frontend」ディレクトリ以下にVisual Studio向けのプロジェクトファイル「faac.sln」が含まれているので、これをVisual Studioで開いてコンパイル設定を行えば良い。
約4分のWAVE形式音声ファイルをFAACのデフォルト設定でエンコードし、エンコードが完了するまでの時間を測定した。結果は次の表11のとおりだ。FAACについてもLAMEと同様、インテル コンパイラーを使用することでパフォーマンスの向上が確認できる。
コンパイラ/コンパイルオプション | エンコード時間 |
---|---|
Visual C++(/O2) | 10.7秒 |
インテル コンパイラー(/O3、/Qip) | 8.8秒 |
OpenSSHは、SSHプロトコルによって暗号化されたネットワーク通信を利用してリモートサーバーにアクセスしたり、ファイルを送受信するためのツールだ。
SSHプロトコルではRSAやDSAといった公開鍵暗号を利用して通信内容を暗号化し、安全な通信を実現している。しかし、RSAやDSAによる暗号化/復号処理はそれなりに計算量が必要であるため、インテル コンパイラーを使用することで処理の高速化が期待できる。
OpenSSHのコンパイルには、OpenSSHのほかデータ圧縮/展開ライブラリ「zlib」やOpenSSLに含まれる「libcrypt」が必要だ(コンパイル設定によってはそのほかのライブラリも必要であるが、今回は最小限の構成でコンパイルを行っている)。まずはこれらをインテル コンパイラーでコンパイルし、最後にOpenSSHをコンパイルすることになる。
なお、以下では「~/local/」ディレクトリ以下にこれらをインストールするよう設定を行っている。それ以外のディレクトリへのインストールを行う場合は適宜「prefix=」以下を変更してほしい。
まずzlibのコンパイルであるが、zlibのソースアーカイブはzlibのWebサイトから入手できる。今回はzlib 1.2.3(アーカイブファイルは「zlib-1.2.3.tar.gz」)を使用した。このアーカイブファイルを適切なディレクトリに展開し、次のように実行する。
$ cd zlib-1.2.3 $ CC=icc CFLAGS="-O3 -ip" ./configure --shared $ make make install prefix=$HOME/local
また、~/local/ディレクトリ以下にインストールされたライブラリを使用するため、下記のように「LD_LIBRARY_PATH」環境変数を設定しておく。
export LD_LIBRARY_PATH=~/local/lib/:$LD_LIBRARY_PATH
以上で、~/local/lib/ディレクトリ以下にzlibのスタティックライブラリおよび共有ライブラリがインストールされ、利用可能になる。
続いて、OpenSSLのコンパイルを行う。ソースアーカイブは公式Webサイトから入手が可能だ。今回はOpenSSL 0.9.8(アーカイブファイル名は「openssl-0.9.8k.tar.gz」)を使用した。
適切なディレクトリにアーカイブを展開し、以下のように実行する。
$ cd openssl-0.9.8k $ CC=icc ./config --prefix=$HOME/local --shared $ make $ make test $ make install
最後に、OpenSSH本体のコンパイル作業を行う。OpenSSHのソースアーカイブは、ミラーサイト(JAIST)から入手可能だ。今回はOpenSSH 5.2p1(アーカイブファイル名は「openssh-5.2p1.tar.gz」)を使用した。ダウンロードしたアーカイブを展開後、以下のように実行する。
$ cd openssh-5.2p1 $ CC=icc CFLAGS="-O3 -ip -I$HOME/local/include" LDFLAGS="-L$HOME/local/lib" ./configure --prefix=$HOME/local --with-privsep-path="$HOME/local/empty" $ make $ make install
以上の作業が完了すると、~/local/bin/ディレクトリ以下に「ssh」や「scp」、「sftp」といったSSH関連コマンドがインストールされているはずだ。
コンパイラの違いによる差異を確認するため、sftpコマンドを使用してファイルをアップロード/ダウンロードするのにかかった時間を測定した。使用した環境は次の表12のとおりである。また、コンパイルオプションについてはデフォルトの設定を用いた。
構成要素 | サーバー側 | クライアント側 |
---|---|---|
CPU | Core 2 Duo E6550(2.33GHz) | Core i7 920(2.66GHz) |
メモリ | 2GB | 3GB |
ネットワークインターフェイス | 10/100BASE-TX | 1000BASE-T |
OS | Windows Vista Business SP2 | Debian GNU/Linux 5.0 |
サーバー/クライアントソフト | freeSSHd | OpenSSH |
以上の環境で、約660MBのDebian GNU/Linux 5.0インストールCDイメージをアップロードおよびダウンロードするのにかかった時間を測定したところ、次の表13のような結果となった。
条件 | コンパイラ | かかった時間 | 転送速度 |
---|---|---|---|
アップロード | インテル コンパイラー | 64秒 | 約10.3MB/s |
GCC | 64秒 | 約10.3MB/s | |
ダウンロード | インテル コンパイラー | 58秒 | 約11.4MB/s |
GCC | 59秒 | 約11.2MB/s |
ファイル転送ではネットワークの速度がボトルネックになることが多いため、残念ながら今回の検証結果ではコンパイラの違いによる差は誤差の範囲内でしか見られなかった。
いくつかのオープンソースソフトウェアを実際にコンパイルしてみたが、多くのソフトウェアの場合インテル コンパイラーで簡単にコンパイルが可能である。さらに、ソースコードの修正を加えずとも、インテル コンパイラーを使用するだけでパフォーマンスの向上が見られたソフトウェアも多くあった。
インテル コンパイラー 1000本ノックプロジェクトでは、これからもインテル コンパイラーによるオープンソースソフトウェアのコンパイルを行っていく予定だ。また、プロジェクトではインテル コンパイラーを使用して作成したソフトウェアの紹介や、コンパイルしてほしいソフトウェアの希望などもプロジェクトのフォーラムで受け付けているので、気軽に意見を寄せてほしい。
[ページ情報]
更新日時: 2009-11-16 19:39:39, 更新者: hiromichi-m
[権限]
表示:無制限, 編集:ログインユーザ, 削除/設定:メンバー