インテル製コンパイラ icc の FreeBSD サポート開始 48
ストーリー by yoosee
でーもん君高速化ドーピング 部門より
でーもん君高速化ドーピング 部門より
BSD 曰く、 " Alexander Leidingerが 関係者にあてたメール (日本語訳)によると、 icc によって FreeBSD カーネルをコンパイルするためのパッチがコミットされたとのことだ。 インテルの icc コンパイラを入手するにはライセンスを取得しなければならないが (参考情報)、 ライセンス取得し icc をダウンロードすれば、誰でも簡単にカーネルが再コンパイル できるようだ。i386系では icc は gcc より最適化されたコードを 生成するので、新しいカーネルは従来のものより多少速く動くようだ。 そのうち、i386系はカーネル、ユーザランドの両方とも icc でコンパイルされた バイナリが配布されるようになるのかもしれない。"
コンパイラを変えてカーネルを作る意味 (スコア:4, 興味深い)
複雑怪奇なループ構造がある数値計算がメインなプログラムで、何度も使うもので速度がとっても重要である、というのならiccを使う意味は大きいと思います。まあマシンとコードによりますが、大抵においてgccよりは良い速度になるので(そうじゃないのもあるわけですが)。
でも、カーネルとかデバイスドライバって、そういった部分ってそんなにない気がしています。ハードを待つ時間とかの方がよっぽど大きいわけで、その待つ時間をpollingではなく他の仕事が出来るよう、うまくlockとかpreemptiveの仕組みとかを用意することの法が重要に思えます。
また、iccが超優秀で、たとえばメモリコピーのコードにprefetchをうまくはさんでくれて、速度が30%改善!とかになったとしても、アルゴリズム的な改善(RCUとか使ってコピーそのものをなくすとか)されたら、ひとたまりもありません(まあこれは一般的なプログラムでも当てはまることではあるのですが)。
そんなわけで、どっちかというとportsとかを全部iccでコンパイルできるようにパッチを用意しました!とかを期待したいなあと思ってたり。出来る限り自分の書くコードはgccでもiccでも通るように頑張ってますが世間一般ではそうじゃないのがちょっと残念だったりします。
-- Takehiro TOMINAGA // may the source be with you!
Re:コンパイラを変えてカーネルを作る意味 (スコア:1, 参考になる)
> ものすごく素朴な疑問なんですが、iccでカーネル作ってうれしいのでしょうか…?
> いやもちろん技術的には面白いのはわかるのですが。
> 出来る限り自分の書くコードはgccでもiccでも通るように頑張ってますが
> 世間一般ではそうじゃないのがちょっと残念だったりします。
BSD氏の日記にあるFreeBSD: 半期毎状況報告 [srad.jp]によると
とのことなので、FreeBSDの中の世間一般の人も頑張っているのですよ。
Re:コンパイラを変えてカーネルを作る意味 (スコア:1)
速度は余り問題にならなさそうなところではなく、速度が重要視されるアプリにおいて「世間一般の人が」いまいちな対応しかしてないところがやだなー、といいたかったんですが舌足らずでしたねすいません。
個人的にはエラーメッセージなり警告なりが云々、というのはどっちかというとlintでも使えよという気がしないでもないです。
-- Takehiro TOMINAGA // may the source be with you!
Re:コンパイラを変えてカーネルを作る意味 (スコア:1, 参考になる)
Re:コンパイラを変えてカーネルを作る意味 (スコア:0)
カーネルが速くなるとうれしいですね。
#逆にどの程度クライアントとして使用する人が
#いるのかが知りたいです。
Re:コンパイラを変えてカーネルを作る意味 (スコア:0)
icc で性能が出るのであれば icc を使えばいいのです。
ポータビリティをあげる努力に使う時間は、性能向上に使ってください。そのほうが世のためです。
Re:コンパイラを変えてカーネルを作る意味 (スコア:0)
少なくとも私のためにはならないなあ。
# ちょっと両隣の人に聞いたが、彼女らもためにならないそうだ。
Re:コンパイラを変えてカーネルを作る意味 (スコア:0)
icc による性能向上が期待できるのであれば、ポータビリティ向上の努力は世のためになるのでは?
たれ込みに対する評価をすることはできないの？ (スコア:2, すばらしい洞察)
たれ込み中の変なコメントが多すぎる気がします。
Re:たれ込みに対する評価をすることはできないの？ (スコア:1)
モデレートされた結果掲載されてるということでしょう。
そうはいっても、たれこみ元も編集者も完璧じゃないでしょうから、
> たれ込み中の変なコメントが多すぎる気がします。
もし気になってしょうがないのであれば、それをここで具体的に指摘してあげればいいのではないでしょうか。
(例えば、既に指摘されていますが、記事のタイトルは逆の意味に読めますね)
ま、タレコミ自体は議論のきっかけだと思ってるので、タレコミ文自体にクドクドとケチをつけてもしょうがないんじゃないのかな、という気もしますけどね。新聞や雑誌のようなこちらが読者として受身にならざるを得ないメディアなら、それも意味があるのでしょうけど。
1次ソースをよく読みましょう (スコア:1)
Re:1次ソースをよく読みましょう (スコア:1)
始めの、
> icc によって FreeBSD カーネルをコンパイルするためのパッチがコミットされた
という文は、「icc に、icc によって FreeBSD カーネルをコンパイルするためのパッチがコミットされた」という意味にも読めてしまい、タイトルの
> インテル製コンパイラ icc の FreeBSD サポート開始
と相まって、インテルがパッチのコントリビュートを受けて、icc for FreeBSD を作ったよう解釈できちゃいます。
書くなら、それぞれ、
「FreeBSD カーネルに、icc でコンパイル可能にするパッチがコミットされた」
「FreeBSD が icc でのコンパイルを正式サポート」
とかが適切だと思います。
なんちゃってプログラマ?
Re:1次ソースをよく読みましょう (スコア:0, フレームのもと)
ああそうだったんですか。じゃ、「インテルの icc コンパイラを入手するにはライセンス云々」に相当する元のメールの個所を示していただけますか？見つけられなかったもので。
それから「そのうち、i386系はカーネル、ユーザランドの両方とも icc でコンパイルされたバイナリが配布されるようになるのかもしれない」についても、元のメール内でその主旨の発言をしているところを教えてくださいな。「ライセンス的に配布は可能なんだけど、とてもじゃないがまだまだでき
Re:1次ソースをよく読みましょう (スコア:0)
見苦しいよ
Re:たれ込みに対する評価をすることはできないの？ (スコア:0)
Re:たれ込みに対する評価をすることはできないの？ (スコア:0)
>> icc でコンパイルされたバイナリが配布されるように
>> なるのかもしれない。"
この1文のみたれこみ人としての「コメント」だと思われますが、
これ以前の3文からどうしてこのようなコメントが生まれる
のか、、あまりに短絡的なロジックではないでしょうか？
読んだ人は「なんで、突然そういう話になるのよ？」と疑問に
思っちゃうでしょう。
体験版ゲッツ (スコア:2)
その昔、学生のころに、体験版をダウンロードして、
自分のプログラムをコンパイル＆実行したことがあったのだけれど、
Borland bcc32 でも、GNU gcc でも、icc でもあまり性能が変わらなかったのは、
数値計算プログラムだったからか、
それとも、それ以上に酷いプログラムを書いていたからか…。
# この時期の大学の計算機資源(スパコン)は混みあっているので
# 自分のパソコンで走らせたほうがはやかった罠…
Re:体験版ゲッツ (スコア:1)
「劇的に」速くなる訳じゃないですよ。
たかが数%、よくて20%程度ですし。
やっぱり普段からいかに最適化されたプログラムを書くかが
性能には一番効くのではないでしょうか。
ただ、その計算機に最適化されたプログラムというのは
必ずしも「きれいな」プログラムではないのが難しいところ。
手で行列を分割したり、loopをunrollしたりするので
スパゲッティになりがちです。(笑)
Re:体験版ゲッツ (スコア:0)
Re:体験版ゲッツ (スコア:1)
キャッシュに籠ってループをガンガン回すコードを書いたほうが速いよねぇ。
Ｃで書くと、条件判断のとこで遅くなるんだっけ？
Scott Long の見解 (スコア:2, 参考になる)
Re:Scott Long の見解 (スコア:1)
カスタムブート用フロッピーディスクイメージ作成webサービス
ってのはどうだってのが
何年か前にコンダラの人の日記であったなぁ、
というのを思い出した。
どちらも結構すぐに実現は出来そうではあるのに
どこもやらないっすね。
何を根拠に？ (スコア:1, すばらしい洞察)
>> icc でコンパイルされたバイナリが配布されるように
>>なるのかもしれない。
ほんとかいなー。。。！？！？
Re:何を根拠に？ (スコア:2, 興味深い)
- ライセンス
- 互換性
- コミュニティ内の同意
生成コードの質だけで覆せないでしょ。また gdb やプロファイラの様な開発環境全体の対応とか、エラーメッセージの出方(タグジャンプで使うので大事)とか簿妙に調整しなければいけない要素やまづみです。
むしろ GCC 開発陣営が刺激を受けて奮起してくれる方向の期待度は高いです。
コード生成を「真似」するのって著作権的にOKなのかとか微妙な話もありますが…
Re:何を根拠に？ (スコア:3, 参考になる)
> Note to committers: we have a commercial icc license, so we're allowed
> to distribute icc compiled binaries (but we're far away from being able
> to build an entire release with icc).
とあるので、やろうと思えば可能なようです。
Re:何を根拠に？ (スコア:3, 興味深い)
ライセンスに関しては、商用ライセンスを既に取得している旨がリンク先の末尾に書かれてますし、バイナリ配布は問題なさそうです。
いつぞやIntelからライセンスを寄付されたとかいう話があったような。どこで見たんだっけ?
>互換性
コンパイラ以外の周辺ツールの対応状況は気になります。全く使えない事はないだろうけども、いやな感じな事が起こりそうな…。
バイナリの互換性については、iccで作ったカーネルとgccで作ったとモジュールが(あるいはその逆も)一緒に使えるようです。
以前出ていたNFSが使えない問題とかは解決したのかな。
>コミュニティ内の同意
こればっかりは、今後の動向を見守るしかないですね。あるいは1ユーザーとして動向の一部を担いましょう。:)
現状、カーネルのサポートだけとcurrent-MLに流れてたので、worldまでできたら個人的に試してみようと思ってます。
ports関連はiccにすると通らないものが多いみたいですね。devel/stlport-iccのようなものが大量にできるか、Mkの中身が大幅に変わるかだと、後者の可能性が高いかな。
# と、日曜昼間に(内容含め)だらだらと書き込み
Re:何を根拠に？ (スコア:3, 参考になる)
いかにも /.J らしい無責任な発言が横行 (ACに限らず) しているので、誤解を与えそうな箇所を指摘しておく。
商用ライセンスを取得したのは、元のメールでいう「We」であることを忘れないように。商用ライセンスを取得した人や団体は当該ライセンスの下でバイナリを配布できる。
第三者である任意のFreeBSDユーザがバイナリを配布する場合は、各自でIntelと契約を結んだ上でその契約に従って行う必要がある。
Re:何を根拠に？ (スコア:1)
当たり前といえば当たり前なんですが、確かに誤解を招きそうな書き方でしたね。ご指摘ありがとうございます。
で、件の非商用ライセンス、ちょっと抜き出すと
と書いてあります。金銭授受とそれに類するものを伴う形での成果物の実行・生産が禁止なのは当然なんですが、そうでない場合の配布に関する部分がちょっとわからないんですよね。
配布に関する条項が、商用・非商用の区別のないところに書かれているけど、研究目的からはずれるからだめかなぁ。Intelに確認してみるしかない。
と、これだけでは何なので、おまけ。
current-MLでもバイナリ配布の話題が出てますね。GENERIC以外のカーネルをコンパイルするのに結局ユーザーがiccを持ってる必要になるじゃないか、みたいなことをScott氏が言ってます。そりゃそうだ。
Re:何を根拠に？ (スコア:1)
>> icc でコンパイルされたバイナリが配布される
のに
> gdb やプロファイラの様な開発環境全体の対応とか、エラーメッセージの出方(タグジャンプで使うので大事)とか
はあまり関係ないのでは？
Re:何を根拠に？ (スコア:1, 参考になる)
>> gdb やプロファイラの様な開発環境全体の対応とか、エラーメッセージの出方(タグジャンプで使うので大事)とか
が、大きく関係するんですよ。
# iccに対応した開発環境がないと、そもそもバイナリ配布まで
# こぎ着けないでしょ、って話。
Re:何を根拠に？ (スコア:0)
コンパイラかえてリコンパイルで通ると思うので、
CC=gccで開発して、CC=iccでリリースすればよいのでは？
Re:何を根拠に？ (スコア:1)
コンパイラ間の差異が少ない事が予想される、としても
開発版と違うコンパイラ使ってリリースをビルドするのはリスクが高いと思いますが。
Re:何を根拠に？ (スコア:0)
icc の gcc との互換性がどれくらいかは知らないのでただの一般論ですが、ありますよ。
例えば gdb はバイナリに埋めこまれたデバッグ情報を参照しています。ソースコードがあってデバッグオプションを有効にしていれば、実行時にソースの
Re:何を根拠に？ (スコア:1)
高いのかな？
別に競合するコンパイラがあるからといってGCCが刺激を受けるとは限らないと思います。
Intelに限らずプロセッサメーカはコンパイラ出してたりしません？
ちなみに過去にintelはGCCを30%ほど高速化するパッチを出してますよね。
GCC→egcs→Pentium GCCあたりがそのコードを取り込んでませんでしたっけ？
http://www.goof.com/pcg/pgcc-faq.html#SEC0118
これって少なくともGCC 2.9系で取り込まれてますよね？
ところで3.4リリースって近いのかな？
Re:何を根拠に？ (スコア:0)
GCCが30%高速化されたらとてもうれしい。
# GCC3.4 snapshotのPCH使っても全然速くならないです。
Re:何を根拠に？ (スコア:1, おもしろおかしい)
30%高速なgccが出来る気がする。理論上は。
Re:何を根拠に？ (スコア:0, 余計なもの)
Re:何を根拠に？ (スコア:0)
Re:何を根拠に？ (スコア:0)
Re:何を根拠に？ (スコア:0)
「icc の FreeBSD サポート開始」って (スコア:1)
Re:「icc の FreeBSD サポート開始」って (スコア:0)
Re:「icc の FreeBSD サポート開始」って (スコア:1, すばらしい洞察)
「iccを用いたFreeBSDカーネルコンパイルが可能に」
くらいが適当？
INTEL for AMD (スコア:1, 興味深い)
どんなパフォーマンスになるんでしょう？
あまり情報がないもんで。
Re:INTEL for AMD (スコア:5, 参考になる)
きちんとコンパイラオプションを設定してあげれば
Athlon でも icc の方が速くなることが多いようです．
#ただし，プロファイラからの出力で最適化してやらないと
#あんまし意味ない
例えば Spec に載っている AMD の CPU を使った計算機の結果も
icc によって出た値です．コンパイラのオプションなどは，
ここらあたりが参考になるでしょう．
http://www.spec.org/cpu2000/results/res2003q2/cpu2000-20030505-02154.html
ただ，正直な話，gcc も 3系になってからは template まわりは
まともにサポートするようになったし，速度も icc とそれ程かわらない
ようなので，自分はわざわざ icc を使うようなことはしていません．
また，icc と gcc とでは C++ の Hash Map あたりの扱いなどを含め，
コードの互換性を保つためには工夫が(ちょっとだけ)必要なので
icc 導入の苦労に見合うかどうかは微妙です．
Re:INTEL for AMD (スコア:1)
>まともにサポートするようになったし，
ん、(過去の)boost regression testなどを見ても、初期のiccのほうが
よっぽど酷かったと思うけどなぁ。v6あたり。
>また，icc と gcc とでは C++ の Hash Map あたりの扱いなどを含め，
>コードの互換性を保つためには工夫が(ちょっとだけ)必要なので
"C++"のHashMapって？標準規格にないクラスをあたかもそうである
かのように扱ったらそりゃ面倒はあるでしょう。
その昔 (スコア:3, おもしろおかしい)
NECのWin3.1よりも高速に動作した、みんなEPSONのWin3.1を
NEC PC-98で動かした、という話を思い出してしまった。
-- gonta --
"May Macintosh be with you"
icc メモ (スコア:1)
以下、メモ
「それがどうした、おれたちには関係ない」