IntelがClangベースのC++コンパイラを開発 41
ストーリー by hylom
普及が進むというべきか、利用されているというべきか 部門より
普及が進むというべきか、利用されているというべきか 部門より
あるAnonymous Coward 曰く、
Intel独自のコンパイラ（Intel Compiler）はIntel CPU向けの最適化が施されていることで一部では有名だが、このたびオープンソースのコンパイラ環境LLVMの一部として開発されているC++フロントエンドClangを使ったコンパイラをIntelが開発したそうだ。
資料PDFによると、C++フロントエンドとしてClangを使ってLLVM中間コード（IR）を生成したのち、プロプライエタリなIntel製のコンパイラでその中間コードをネイティブコードにコンパイルする、という仕組みのようだ。
Clangのは最新のC++規格のサポートが進んでいることに加え、最新版のClangではOpenMP 4.0やCilk PlusといったIntel独自機能もIntelからの貢献により利用できるようになっているという。これにより、Intel CompilerではC++最新規格との高い互換性を実現でき、またOpenMP 4.0やCilk Plusといった技術をClangに提供することでオープンソース的な貢献もできるとしている。
出典がよく分からなかったんですが (スコア:5, 参考になる)
2014年4月7,8日に開催された「2014 European LLVM Conference [llvm.org]」でポスター展示されたみたいですね
現行のIntel C++ Compiler 14.0のマニュアル見てみると
User and Reference Guide for the Intel® C++ Compiler 14.0「Compatibility Options : clang-name [intel.com]」とかの説明に
とかあったりするので、着実に対応が進んでる、ってことなんでしょうかね
LLVMの真骨頂 (スコア:0)
Re:LLVMの真骨頂 (スコア:1)
Intelコンパイラの顧客が最新の言語仕様を使えるようになっただけで、LLVMは実績が１つ増えただけの事だね。
Re: (スコア:0)
対応が面倒な最新言語規格への対応はLLVMに任せて、プロプライエタリなバックエンドを頑張るという風に読めましたが。
Re: (スコア:0)
フロントエンドが行う各言語からllvmまでの最適化の比重ってどれくらいなんでしょうか。
llvmの中間コードってごく普通のレジスタマシンなので、JavaVMみたいなスタックマシンと違ってバックエンドの最適化の比重は低いと思ってました。
Re:LLVMの真骨頂 (スコア:1)
長年のIntelの蓄積、経験、感が頼りにされる、Intelにしかできない仕事があると思います。
Re:LLVMの真骨頂 (スコア:1)
ｌｌｖｍのレジスタマシンはｘ86+FPUに類似していて、現状のバックエンドはシンプルで済む反面、SSEなどの拡張命令を利用した最適化は申し訳程度。
そのため、自社CPUを知り尽くしたIntelが、ＡＶＸなどの新命令セットの利用に加え、uOPやパイプラインなどのマイクロアーキテクチャを考慮したバックエンドの最適化により、それなりの性能向上が期待できますね。
AMDもOpenCLとｌｌｖｍベースでAPUのHSAを作っていますし、非x86でもバックエンドの最適化はホットな話題と思います。
Re: (スコア:0)
いろんなものが速くなりますね。
Intelコンパイラは速いかもしれんけどClangは遅いままでしょ
Re: (スコア:0)
コンパイラではなく、コンパイルして出来上がったアプリが速くなると元コメは言っているんでしょ。
Re: (スコア:0)
Clangの生成するコードの質は変わらん → 影響なし
Intelコンパイラの生成するコードの質は変わらん → 影響なし
GCCの生成するコードの質は変わらん → 影響なし
VCの生成するコードの質は変わらん → 影響なし
何が速くなるという主張??
Re: (スコア:0)
Clangの生成するLLVMで動作するコードの質は変わらん → 影響なし
LLVMからネイティブへのコンパイラをIntelが改良→影響あり
Re:LLVMの真骨頂 (スコア:1)
Re: (スコア:0)
フロントエンドはともかく、バックエンドは Intel Compiler でしか使えんよ
Re: (スコア:0)
llvmという同じインフラで、コストを惜しまなければエンジンだけ交換っていうのが出来るっていうのは大いに結構だと思うんですが。
Re: (スコア:0)
別に何の問題もないですよ？
ただ単に、(Intel Compiler ではなく) 普通の LLVM/Clang でコンパイルしたアプリが速くなるわけではないよ、というだけの話で。
部門名 (スコア:0)
Intelのこれまでの貢献を知ってて「利用されているというべきか」と言うからにはhylomは余程凄い貢献をしてきたんですね。（棒
この手の幼稚なアンチ巨人・アンチプロプラには反吐が出るわ。
Re:部門名 (スコア:1)
/.jの編集をするのってOSSに対する貢献だと思う。
640GBはすべての人にとって未来永劫充分なメモリだ。
Re: (スコア:0)
住人のレベルが2ch並みにまで落ちたサイトがどうOSSに貢献すると？
Re: (スコア:0)
もとから2chと大差ないんですけど
Re:部門名 (スコア:1)
昔はそうでもなかったぞ。
みんなエラくなって時間がなくなったか、情熱を失ったか。
いずれにせよ/.Jが世代交代に成功しなかったのは事実かも。
Re: (スコア:0)
「利用されているというべきか」はClangにかかってるんでしょ。
Re:部門名 (スコア:2)
IntelがClangを利用されていると言うべきか。
Re: (スコア:0)
Clangがただ乗りされるのはどうか、って言いたいんだよね。
それを禁止するとどうなるかはGCCが教えてくれている
Re: (スコア:0)
Intelが利用されていると言うべきか、と書きたかった？
Re: (スコア:0)
Re: (スコア:0)
だからって広島のアンチなんてしない。
どうせすぐ落ちるから。
Re:部門名 (スコア:1)
なにDeNAなんて安定ですよ.
動機 (スコア:0)
ちょっと待てみんな、これ Clang の将来性とか性能の話じゃなくって、Mac OS X の libstdc++-4.2.1 ではどう逆立ちしても C++11 とか C++14 とか対応できなくなってきた為だからじゃないのか。
Re: (スコア:0)
ということにしたいのですね
Re: (スコア:0)
何でそう思っちゃったのカナ？？
Re: (スコア:0)
バカなの?
Re: (スコア:0)
もしそれだけだったら、Intelはコンパイラを変える必要はないですよね。libc++を使ったり、Mac OS X付属に拘らなければ最新のlibstdc++を使えばよいだけなのですから。
Re: (スコア:0)
libstdc++のようなライブラリの修正だけでは、C++11やC++14には殆ど対応できません。
C++11 とか C++14 は C++の構文レベルでの仕様変更が目玉なので、
コンパイラ側の構文解析器のソースコードの修正が必要です。
今までintelは独自にC++のコンパイラを全部自前で作ってきたわけですが
clang/llvm のフレームワークに乗っかれば
構文解析器はclangのものがそのまま流用できるので、
開発がかなり楽になる、という点が一番大きいと思います。
Re: (スコア:0)
> 今までintelは独自にC++のコンパイラを全部自前で作ってきたわけですが
フロントエンドはエジソンだけど
Re: (スコア:0)
ちなみに10年以上前のサイトの記述ですが、エジソンのC++パーサは40万行もあったそうです
Re: (スコア:0)
いや全くもってその通りだから、
> Mac OS X の libstdc++-4.2.1 ではどう逆立ちしても C++11 とか C++14 とか対応できなくなってきた為
というのは文章としておかしいってことでしょ。
コンパイラも変えなきゃダメだというのはその通りで、わざわざlibstdc++を持ち出さなくてもいいし。
#2593344 への返信として直接ぶら下げてたら完全同意かな。
Re: (スコア:0)
なんでMac限定？
それにOS Xって既にGCCからLLVMに移行してるんじゃなかったっけ。
Re: (スコア:0)
元コメ主です。
不慣れでちと荒れてしまいましたがここにぶら下げてみます。
Mac 限定なのは、OS X が GCC を捨てて Clang に移行しているのに Intel Compiler (icc/icpc)は GCC 環境に依存していた為です。
・Intel Composer XE 2012 辺りまでは幸せでした。
当初のサポート対象は OS X 10.5 と 10.6。Linux 版との GCC バージョンの違いもそう無いため、Linux と同じコードがコンパイルできました。
・Intel Composer XE 2013 SP1 (icpc version 14) で Mac OS X だけ取り残されました。
SP1 でついに RHEL5 が deprecated になりRHEL6 の gcc-4.4 が最古