CentOS 5 を実行している AMD Opteron サーバーを使用しています。かなり大規模な C++ Boost ベースのプログラム用のコンパイラが必要です。どのコンパイラを選択すればよいですか?
9 に答える
多数のコンパイラを比較した興味深いPDFがここにあります。
これが痛い以上に役立つことを願っています:)
私は 1 年以上前にちょっとしたコンパイラの銃撃戦を行いましたが、記憶がなくなっています。
- GCC 4.2 (アップル)
- インテル10
- GCC 4.2 (アップル) + LLVM
私は、自分が書いた複数のテンプレートを多用した音声信号処理プログラムをテストしました。
コンパイル時間: Intel コンパイラは、最も遅いコンパイラでした。別の投稿が引用したように、「2 倍遅い」以上でした。
GCC は、Intel と比較して、深いテンプレートを非常にうまく処理しました。
Intel コンパイラは巨大なオブジェクト ファイルを生成しました。
GCC+LLVM は最小のバイナリを生成しました。
生成されたコードは、プログラムの構造と SIMD が使用される可能性があるため、大幅に異なる場合があります。
私の書き方では、GCC + LLVM が最適なコードを生成することがわかりました。(私が書いたように) 最適化を真剣に考える前に私が書いたプログラムについては、一般的に Intel の方が優れていました。
インテルの結果はさまざまでした。いくつかのプログラムをはるかにうまく処理し、いくつかのプログラムをはるかに悪く処理しました。それは生の処理を非常にうまく処理しましたが、GCC + LLVM にケーキを与えます。なぜなら、より大きな (通常の) プログラムのコンテキストに入れると... うまくいったからです。
Intel は、すぐに使用できる巨大なデータ セットの数値計算で勝利しました。
GCC 単独では最も遅いコードが生成されましたが、測定とナノ最適化を使用すると同じくらい高速になる可能性があります。いわば、次のコンパイラのリリースで風向きが変わる可能性があるため、それらを避けることを好みます。
このテストでは、よく書かれていないプログラムを測定したことはありません (つまり、一般的なパフォーマンス ライブラリのディストリビューションよりも優れた結果が得られました)。
最後に、プログラムは数年にわたって作成され、当時は GCC を主要なコンパイラとして使用していました。
更新: Core2Duo の最適化/拡張も有効にしていました。プログラムは、厳密なエイリアシングを有効にするのに十分クリーンでした。
コードによって異なると思いますが、現在取り組んでいるコードベースでは、ICC 11.035 は Xeon 5504 上の gcc 4.4.0 よりもほぼ 2 倍の改善をもたらします。
icc オプション: -O2 -fno-alias
gcc オプション:-O3 -msse3 -mfpmath=sse -fargument-noalias-global
オプションは、エイリアシングがないことを知っている、計算集約型のコードを含むファイルだけに固有のものです。5 レベルのネストされたループを持つシングルスレッド コード。
自動ベクトル化が有効になっていますが、どちらのコンパイラもベクトル化されたコードを生成しません (コンパイラの障害ではありません)。
更新 (2015/02/27): いくつかの地球物理学コード (2013 年第 2 四半期) を Sandy Bridge-E Xeon で実行するように最適化しているときに、ICC 11.1 と GCC 4.8.0 のパフォーマンスを比較する機会がありました。 ICC よりも高速なコード。コードは AVX 組み込み関数を使用し、8 ウェイのベクトル化された命令を使用していました (特定のデータ レイアウト要件により、どちらのコンパイラもコードを適切に自動ベクトル化していませんでした)。さらに、GCC の LTO 実装 (IR コアが .o ファイルに組み込まれている) は、ICC よりも管理がはるかに簡単でした。LTO を使用した GCC は、LTO を使用しない ICC よりも約 3 倍速く実行されました。LTO なしの GCC の数値は今のところわかりませんが、それでも ICC よりも速かったことを思い出します。これは決して ICC のパフォーマンスに関する一般的な声明ではありませんが、結果は GCC 4.8.* を進めるのに十分なものでした。
GCC 5.0 ( http://www.phoronix.com/scan.php?page=article&item=gcc-50-broadwell ) を楽しみにしています!
インテル®コンパイラーは、当社の製品(DB2)、LinuxおよびWindows IA32 / AMD64、およびOS X(つまり、SunAMDを除くすべてのインテル®プラットフォーム・ポート)で使用しています。
数値はわかりませんが、パフォーマンスは十分に優れているため、次のことができます。
- 私が言われたコンパイラの代金は非常に高価です。
- ビルド時間が2倍遅くなります(主に、実行を許可する前にライセンスの取得に費やす時間のため)。
PHP -GCCではなくICCを使用してソースからコンパイルすると、速度が10%から20%向上するはずです-http ://www.papelipe.no/tags/ez_publish/benchmark_of_intel_compiled_icc_apache_php_and_apc
MySQL -GCCではなくICCを使用したソースからのコンパイルにより、速度が25%から50%向上するはずです-http ://www.mysqlperformanceblog.com/files/presentations/LinuxWorld2005-Intel.pdf
openSUSE 12.2 (カーネル 3.4.33-2.24-default x86_64) でUnixBench (v. 5.1.3)を使用し、最初に GCC でコンパイルし、次に Intel のコンパイラでコンパイルしました。
1 つの並列コピーでは、Intel でコンパイルされた UnixBench は、GCC でコンパイルされたバージョンよりも約 20% 高速です。しかし、これには大きな違いが隠されています。Dhrystone は Intel コンパイラで約 25% 遅くなりますが、Whetstone は 2 倍速く実行されます。
UnixBench の 4 つのコピーを並行して実行すると、GCC に対する Intel コンパイラの改善はわずか 7% です。ここでも、Intel は Whetstone (> 200%) ではるかに優れており、Dhrystone (約 20%) で低速です。
インテル® コンパイラーが定期的に実行する多くの最適化では、特定のソース構文と gcc の -O3 -ffast-math の使用が必要です。残念ながら、-ffast-math -O3 -march=native の -funsafe-math-optimizations コンポーネントは -fopenmp と互換性がないことが判明したため、ソース ファイルを Makefile のさまざまなオプションで名前が付けられたグループに分割する必要があります。今日、-O3 -ffast-math -fopenmp -march=native を使用した g++ ビルドが画面に書き込むことができたが、ファイルにリダイレクトできなかったという障害に遭遇しました。私の意見では、よりひどい違いの 1 つは、icpc による std::max と min のみの最適化です。ここで、gcc/g++ は、fmax|min[f] に -ffast-math を指定して、その意味を標準から変更する必要があります。
以前は、大規模なクラスターで実行されるかなり大規模な信号処理システムに取り組んでいました。以前は重い計算処理を計算していましたが、Intel コンパイラは GCC よりも約 10% 少ない CPU 負荷を与えてくれました。それは非常に非科学的ですが、それは私たちの経験でした (約 18 か月前のことです)。
興味深いのは、チップセットをより効率的に使用する Intel の数学ライブラリも使用できた場合です。