これはプログラミング指向のWebサイトのようであるため、この質問をここに投稿する必要があるかどうかはわかりません。
とにかく、これを知っている教祖がここにいるに違いないと思います。
これで、CentOS5を実行しているAMDOpteronサーバーができました。かなり大きなc ++ Boostベースのプログラム用のコンパイラが必要です。どのコンパイラを選ぶべきですか?
私はこれが痛い以上に役立つことを願っています:)
私は1年以上前にコンパイラの銃撃戦を少し行いましたが、メモリを使い果たしてしまいます。
私が書いた複数のテンプレートの重いオーディオ信号処理プログラムをテストしました。
コンパイル時間:Intelコンパイラははるかに遅いコンパイラでした-別の投稿が引用したように「2倍以上遅い」。
GCCは、Intelと比較してディープテンプレートを非常にうまく処理しました。
Intelコンパイラが生成したhugeオブジェクトファイル。
GCC + LLVMは最小のバイナリを生成しました。
生成されたコードは、プログラムの構成やSIMDを使用できる場所によって、大幅に異なる場合があります。
私の書き方では、GCC + LLVMが最良のコードを生成することがわかりました。最適化を真剣に考える前に書いたプログラム(私が書いたように)については、Intelの方が一般的に優れていました。
Intelの結果はさまざまでした。いくつかのプログラムをはるかにうまく処理し、いくつかのプログラムをはるかに悪く処理しました。生の処理を非常にうまく処理しましたが、より大きな(通常の)プログラムのコンテキストに入れると...より良くなったので、GCC + LLVMにケーキを与えます。
Intelは、箱から出してすぐに勝ち、膨大なデータセットの数を減らしました。
GCCだけで最も遅いコードが生成されましたが、測定とナノ最適化で同じくらい速くなる可能性があります。いわば次のコンパイラリリースで風向きが変わるかもしれないので、私はそれらを避けることを好みます。
このテストでは、記述が不十分なプログラムを測定したことはありません(つまり、結果は人気のあるパフォーマンスライブラリの分布を上回りました)。
最後に、プログラムは数年にわたって作成され、当時のプライマリコンパイラとしてGCCを使用していました。
更新:Core2Duoの最適化/拡張機能も有効にしていました。プログラムは、厳密なエイリアシングを可能にするのに十分クリーンでした。
いくつかのコンパイラを比較する興味深い PDFはこちら があります。
MySQLチームは、iccがgccよりも約10%パフォーマンスが向上したことを投稿しました。リンクを探してみます。
一般に、「ネイティブ」コンパイラは、それぞれのプラットフォームでgccよりもパフォーマンスが優れていることがわかりました。
編集:私は少し離れていました。典型的な利益は10%ではなく20-30%でした。一部のナローエッジケースでは、パフォーマンスが2倍になりました。 http://www.mysqlperformanceblog.com/files/presentations/LinuxWorld2004-Intel.pdf
コードによって異なると思いますが、現在取り組んでいるコードベースでは、ICC11.035はXeon5504のgcc4.4.0のほぼ2倍の改善をもたらします。
iccオプション:-O2 -fno-alias
gccオプション:-O3 -msse3 -mfpmath=sse -fargument-noalias-global
オプションは、エイリアシングがないことがわかっている、計算集約型のコードを含むファイルのみに固有です。 5レベルのネストされたループを持つシングルスレッドコード。
自動ベクトル化は有効になっていますが、どちらのコンパイラもベクトル化されたコードを生成しません(コンパイラの障害ではありません)
更新(2015/02/27):Sandy Bridge-E Xeonsで実行するようにいくつかの地球物理学コード(2013年第2四半期)を最適化する際に、ICC11.1のパフォーマンスをGCC4.8.0と比較する機会があり、GCCは現在生成中ですICCよりも高速なコード。コードはAVX組み込み関数を使用し、8方向のベクトル化された命令を使用しました(特定のデータレイアウト要件のため、どちらのコンパイラーもコードを適切に自動ベクトル化しませんでした)。さらに、GCCのLTO実装(.oファイルにIRコアが埋め込まれている)は、ICCよりも管理がはるかに簡単でした。 LTOを使用したGCCは、LTOを使用しないICCの約3倍の速度で実行されていました。現在、LTOなしのGCCの数値を見つけることはできませんが、それでもICCよりも高速だったことを思い出します。 ICCのパフォーマンスに関する一般的な声明ではありませんが、GCC4.8。*を進めるには十分な結果が得られました。
GCC 5.0を楽しみにしています( http://www.phoronix.com/scan.php?page=article&item=gcc-50-broadwell )!
インテル®コンパイラーは、当社の製品(DB2)、LinuxおよびWindows IA32/AMD64、およびOS X(つまり、SunAMDを除くすべてのインテルプラットフォームポート)で使用しています。
数値はわかりませんが、パフォーマンスは十分に優れているため、次のことができます。
[〜#〜] 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
私は以前、大規模なクラスターで実行されるかなり大規模な信号処理システムで作業していました。以前は、数学の処理が重いと考えていましたが、IntelコンパイラーのCPU負荷はGCCよりも約10%少なくなりました。それは非常に非科学的ですが、それは私たちの経験でした(それは約18ヶ月前でした)。
興味深いのは、チップセットをより効率的に使用するIntelの数学ライブラリも使用できたとしたら。
OpenSUSE 12.2(カーネル3.4.33-2.24-デフォルトx86_64)で nixBench (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つは、std :: maxとminのみのicpcによる最適化です。ここで、gcc/g ++は-ffast-mathを使用したfmax | min [f]の意味を標準から変更します。