HPC/並列プログラミングポータルでは、HPC(High Performance Computing)プログラミングや並列プログラミングに関する情報を集積・発信しています。

新着トピックス

インテル コンパイラー 1000本ノックプロジェクト

c54b981ece6b6d02a7a8f19e7b9913ce.png  インテル コンパイラーにはさまざまな最適化機能が備えられており、そのためインテル コンパイラーでコンパイルしたプログラムは高速に動作すると言われている。しかし、そのためだけにわざわざソースコードからコンパイルを行うのは面倒だ、という人も多いだろう。そこで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でしか利用できない機能や若干仕様が異なる部分もあるため、ソフトウェアによってはソースコードの修正等が必要になる場合がある。そこで、まずはインテル コンパイラーで既存のソフトウェアをコンパイルする際の注意点や、知っておくと役立つ事項を紹介しておこう。

インテル コンパイラーのVisual Studio IDEプラグイン

 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」という名称となる。

表1 インテル コンパイラーに含まれるコマンドラインツール(Windows版)
ツールWindows版コマンド名対応するVisual C++付属ツール
C/C++コンパイラicl.execl.exe
リンカーxlink.exelink.exe
ライブラリ/アーカイブ管理ツール(アーカイバ)xilib.exelib.exe
表2 インテル コンパイラーに含まれるコマンドラインツール(Linux/Mac OS X版)
ツールLinux/Mac OS X版コマンド名対応するbinutilsツール
Cコンパイラiccgcc
C++コンパイラicpcg++
リンカーxildld
ライブラリ/アーカイブ管理ツール(アーカイバ)xiarar

 また、インテル コンパイラーでプロシージャ間の最適化機能を有効にしてコンパイルしたオブジェクトファイル(「/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と微妙に異なる言語仕様

 インテル コンパイラーは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との互換性を保つためのオプションも用意されている。

表3 Windows版インテル コンパイラーの互換性オプション
オプション意味
/Qms0C/C++標準規格に準拠する範囲内でVisual C++をエミュレートする
/Qms1/Qms0より多くのバグ/仕様をエミュレートする
/Qms2Visual C++の仕様を最大限エミュレートする
/Qvc7.1Microsoft Visual Studio .NET 2003との互換性を保つ
/Qvc8Microsoft Visual Studio .2005との互換性を保つ
/Qvc9Microsoft Visual Studio .2008との互換性を保つ

 また、Linux/Mac OS X版インテル コンパイラーでは、コンパイラの動作をGCCの特定バージョン互換にするオプションが用意されている(表4)。さらに、Linux/Mac OS X版インテル コンパイラーは独自のC++ライブラリを使用するが、「-cxxlib」オプションを指定することで、GCCに含まれているC++ライブラリやヘッダーファイルを使用してコンパイルを行うことが可能だ。

表4 Linux/Mac OS X版インテル コンパイラーの互換性オプション(抜粋)
オプション意味
-gcc-version=<バージョン>指定したGCCバージョンとの互換性を保つ
-cxxlibGCCに含まれるC++ライブラリおよびヘッダーファイルを使用する

インテル コンパイラーでコンパイル1000本ノック

 以上ではインテル コンパイラーを使用する際の基本的なポイントを紹介したが、もちろんソフトウェアによってはコンパイルのために上記以外の修正が必要な場合がある。そこで例として、「インテル コンパイラー 1000本ノックプロジェクト」で取り上げているオープンソースソフトウェアのいくつかについて、具体的なコンパイル例を紹介しておこう。

 2009年9月末時点で公開しているソフトウェアは、次の表5のとおりだ。また、このうちのいくつかについてはコンパイル方法やパフォーマンス比較も行っている。ここではLAMEや7-Zip、Audacity、x264といったソフトウェアについて触れているが、ここで挙げたソフトウェア以外についても随時追加・更新を行っているので、プロジェクトページの情報もチェックしていただきたい。

表5 2009年9月28日時点でインテル コンパイラー 1000本ノックプロジェクトで公開しているソフトウェア
ソフトウェア名説明対応OS解説
LAMEMP3エンコーダWindows、Linuxコンパイル方法、パフォーマンス比較
7-Zipファイル圧縮/展開ツールWindowsコンパイル方法、パフォーマンス比較
AudacityWindows音声波形編集ソフトコンパイル方法
x264H.264エンコーダWindows、Linuxコンパイル方法、パフォーマンス比較
FAACAACエンコーダWindowsコンパイル方法、パフォーマンス比較
OpenSSHSSHクライアントLinuxコンパイル方法、パフォーマンス比較
bzip2ファイル圧縮/展開ツールLinuxコンパイル方法、パフォーマンス比較
ImageMagick画像ファイル処理ツールWindowsコンパイル方法、パフォーマンス比較
FirefoxWebブラウザWindowsコンパイル方法、パフォーマンス比較
MySQLデータベースシステムLinuxコンパイル方法、パフォーマンス比較

 なお、特に言及がない場合、本記事内でのパフォーマンス検証には次の表6の環境を用いている。

表6 パフォーマンス検証に使用した環境
スペックWindowsでの検証環境Linuxでの検証環境
OSWindows Vista Business SP2Debian GNU/Linux 5.0
CPUCore 2 Duo E6550(2.33GHz)Core i7 920(2.66GHz)
メモリ2GB3GB
コンパイラインテル コンパイラー 11.1、Visual Studio 2008インテル コンパイラー 11.1、GCC 4.3.2

MP3エンコーダ「LAME」

 「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割以上のパフォーマンス向上が見られている。

表7 Windows版LAMEのパフォーマンス比較
コンパイラ/コンパイルオプションエンコード時間
Visual C++(/O2)13.083秒
Visual C++(/O2)+アセンブラ10.992秒
インテル コンパイラー(/Ox、/Qipo)9.740秒
インテル コンパイラー(/Ox、/Qipo)+アセンブラ8.692秒
表8 Linux版LAMEのパフォーマンス比較
コンパイラ/コンパイルオプションエンコード時間
GCC(-O2)8.610秒
GCC(-O2)+アセンブラ7.216秒
インテル コンパイラー(-O3、-ipo)7.348秒
インテル コンパイラー(-O3、-ipo)+アセンブラ5.750秒

ファイルアーカイバ「7-Zip」

 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のコンパイル

 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つである。

  • 大きなファイル(ZIP):約660MBのISOイメージファイルをZIP形式で圧縮
  • 大きなファイル(7z):約660MBのISOイメージファイルを7z形式で圧縮
  • 多数のファイル(ZIP):1648個のファイル(合計約22MB)をZIP形式で圧縮
  • 多数のファイル(7z):1648個のファイル(合計約22MB)を7z形式で圧縮

 測定結果は次の表9のようになった。7-Zipでは最適化オプションとして「/O1」が多用されていることもあり、単純にインテル コンパイラーを使用するだけでは明確なフォーマンス向上は見られないようだ。使用するコンパイルオプションをもう少し吟味する必要があると思われる。

表9 7-Zipのパフォーマンス検証結果
条件コンパイラかかった時間
大きなファイル(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」

 「Audacity」はオープンソースで開発されている波形編集ソフトで、Windows/Mac OS X/Linuxで動作する。

 Windows環境でのコンパイルについては別途wxWidgetsライブラリが必要であり、若干手順が複雑である。ただし、基本的にはAudacity公式Webサイトにある解説、およびソースコード中の「Win」フォルダ内にある「compile.txt」の指示に従えば良い。また、Audacityのダウンロードページ内で配布されているソースアーカイブには一部の依存ライブラリのソースコードが含まれていないため、そちらではなくCVSを用いてソースコードを入手する点に注意してほしい。

 CVSで取得したソースコード中にはVisual Studioのプロジェクトファイルが含まれているので、インテル コンパイラーでコンパイルするにはこれをVisual Studioで開き、LAMEの場合と同様にIDEからインテル コンパイラーを用いるように設定すれば良い。

H.264エンコーダ「x264」

 x264は、GPLで提供されているH.264エンコーダだ。WindowsやMac OS X、Linux/UNIXで動作し、またエンコーダエンジンとしてさまざまなアプリケーションで利用されている。

 x264の公式サイトではソースコードの開発版スナップショットのみが配布されており、x264のWindows向けバイナリはhttp://x264.nl/にて配布されている。また、Gitによるソースコードの取得も可能だ。

Windows環境でのコンパイル

 x264の配布ソースコードには、「build\win32」ディレクトリ以下にVisual Studioのプロジェクトファイルが含まれている。こちらをVisual StudioのIDEで開き、コンパイル設定を行えば良い。

 なお、筆者が試したバージョンのソースコードでは、「C99」と呼ばれる、1999年に策定されたCの新標準規格内で採用された機能が用いられている。そのため、C99に対応していないVisual C++ではそのままではコンパイルできなかった。インテル コンパイラーでは、「/Qstd=c99」オプションを使用することでC99サポートを有効にでき、問題なくコンパイルが可能である。

 また、x264ではSSE2を利用するためのアセンブラで書かれたコードが含まれているのだが、このコードはGCC向けに記述されており、そのままではインテル コンパイラーで利用できない。そのため、Visual C++やインテル コンパイラーでコンパイルしたバイナリは、GCCでコンパイルしたバイナリよりもパフォーマンスが低下してしまう問題がある。

 そのほか、コンパイルを行うために加えた修正点は以下のとおりだ。

  • muxsers.cの296行目「fprintf(stderr, "Bad header magic (%"PRIx32"= %s)\n",」を「fprintf(stderr, "Bad header magic (\"PRIx32\"= %s)\n",」のように修正
  • encoder\looahead.cがプロジェクトファイルとして登録されていなかったので、このファイルを「libx264」プロジェクトに追加

Linux環境でのコンパイル

 Linux環境でのx264のコンパイルでは、configureスクリプトを使用してコンパイル設定を行っている。そのため、次のようにconfigureを実行するだけでコンパイルが可能だ。

$ CC=icc CFLAGS="<コンパイルオプション>" ./configure

パフォーマンス比較(Linux版)

 パフォーマンス比較には解像度720×480、約7秒の動画ファイルを用い、このファイルをデフォルト設定でエンコードした場合のフレームレートを比較した。結果は下記の表10のとおりだ。また、コンパイルオプションについてはデフォルトのものを用いている。結果を見ると、インテル コンパイラーで作成したx264のほうが、若干ではあるがフレームレートが高くなっている。

表10 x264のパフォーマンス比較
コンパイラ平均フレームレート
インテル コンパイラー63.58fps
GCC61.98fps

AACエンコーダ「FAAC」

 現在よく使われている音声圧縮コーデックの1つに「AAC」がある。AACは地上デジタル放送や、アップルのiTunesのデフォルトコーデックとして採用されているコーデックで、低いビットレートでも比較的高音質なのが特徴だ。AAC形式での音声圧縮を行うAACエンコーダはいくつか存在するが、オープンソースで提供されているものとして「FAAC」がある。

 FAACはコマンドラインツールおよびライブラリとして提供されているが、オープンソースで提供されているためほかの動画/音声エンコーダツールなどでも多く採用されている。

FAACのコンパイル(Windows環境)

 FAACのソースコードは、ダウンロードページから入手可能だ。本記事では、2009年2月11日に公開された「faac-1.28.zip」を使用した。このソースアーカイブを展開すると、「frontend」ディレクトリ以下にVisual Studio向けのプロジェクトファイル「faac.sln」が含まれているので、これをVisual Studioで開いてコンパイル設定を行えば良い。

パフォーマンス比較

 約4分のWAVE形式音声ファイルをFAACのデフォルト設定でエンコードし、エンコードが完了するまでの時間を測定した。結果は次の表11のとおりだ。FAACについてもLAMEと同様、インテル コンパイラーを使用することでパフォーマンスの向上が確認できる。

表11 FAACのパフォーマンス比較
コンパイラ/コンパイルオプションエンコード時間
Visual C++(/O2)10.7秒
インテル コンパイラー(/O3、/Qip)8.8秒

SSHクライアント「OpenSSH」

 OpenSSHは、SSHプロトコルによって暗号化されたネットワーク通信を利用してリモートサーバーにアクセスしたり、ファイルを送受信するためのツールだ。

 SSHプロトコルではRSAやDSAといった公開鍵暗号を利用して通信内容を暗号化し、安全な通信を実現している。しかし、RSAやDSAによる暗号化/復号処理はそれなりに計算量が必要であるため、インテル コンパイラーを使用することで処理の高速化が期待できる。

OpenSSHのコンパイル(Linux環境)

 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のとおりである。また、コンパイルオプションについてはデフォルトの設定を用いた。

表12 テストに使用した環境
構成要素サーバー側クライアント側
CPUCore 2 Duo E6550(2.33GHz)Core i7 920(2.66GHz)
メモリ2GB3GB
ネットワークインターフェイス10/100BASE-TX1000BASE-T
OSWindows Vista Business SP2Debian GNU/Linux 5.0
サーバー/クライアントソフトfreeSSHdOpenSSH

 以上の環境で、約660MBのDebian GNU/Linux 5.0インストールCDイメージをアップロードおよびダウンロードするのにかかった時間を測定したところ、次の表13のような結果となった。

表13 OpenSSHのパフォーマンス比較
条件コンパイラかかった時間転送速度
アップロードインテル コンパイラー64秒約10.3MB/s
GCC64秒約10.3MB/s
ダウンロードインテル コンパイラー58秒約11.4MB/s
GCC59秒約11.2MB/s

 ファイル転送ではネットワークの速度がボトルネックになることが多いため、残念ながら今回の検証結果ではコンパイラの違いによる差は誤差の範囲内でしか見られなかった。

インテル コンパイラーでオープンソースソフトウェアのコンパイルに挑戦しよう

 いくつかのオープンソースソフトウェアを実際にコンパイルしてみたが、多くのソフトウェアの場合インテル コンパイラーで簡単にコンパイルが可能である。さらに、ソースコードの修正を加えずとも、インテル コンパイラーを使用するだけでパフォーマンスの向上が見られたソフトウェアも多くあった。

 インテル コンパイラー 1000本ノックプロジェクトでは、これからもインテル コンパイラーによるオープンソースソフトウェアのコンパイルを行っていく予定だ。また、プロジェクトではインテル コンパイラーを使用して作成したソフトウェアの紹介や、コンパイルしてほしいソフトウェアの希望などもプロジェクトのフォーラムで受け付けているので、気軽に意見を寄せてほしい。