アカウント名:
パスワード:
複雑怪奇なループ構造がある数値計算がメインなプログラムで、何度も使うもので速度がとっても重要である、というのならiccを使う意味は大きいと思います。まあマシンとコードによりますが、大抵においてgccよりは良い速度になるので(そうじゃないのもあるわけですが)。
でも、カーネルとかデバイスドライバって、そういった部分ってそんなにない気がしています。ハードを待つ時間とかの方がよっぽど大きいわけで、その待つ時間をpollingではなく他の仕事が出来るよう、うまくlockとかpreemptiveの仕組みとかを用意することの法が重要に思えます。
また、iccが超優秀で、たとえばメモリコピーのコードにprefetchをうまくはさんでくれて、速度が30%改善!とかになったとしても、アルゴリズム的な改善(RCUとか使ってコピーそのものをなくすとか)されたら、ひとたまりもありません(まあこれは一般的なプログラムでも当てはまることではあるのですが)。
そんなわけで、どっちかというとportsとかを全部iccでコンパイルできるようにパッチを用意しました!とかを期待したいなあと思ってたり。出来る限り自分の書くコードはgccでもiccでも通るように頑張ってますが世間一般ではそうじゃないのがちょっと残念だったりします。
> ものすごく素朴な疑問なんですが、iccでカーネル作ってうれしいのでしょうか…? > いやもちろん技術的には面白いのはわかるのですが。
> 出来る限り自分の書くコードはgccでもiccでも通るように頑張ってますが > 世間一般ではそうじゃないのがちょっと残念だったりします。
BSD氏の日記にあるFreeBSD: 半期毎状況報告 [srad.jp]によると
インテル C コンパイラによる FreeBSD のコンパイル URL: http://www.Leidinger.net/FreeBSD/ 担当: Alexander Leidinger FreeBSD に icc を移植し、それによって FreeBSD を再構築している。現在、 パッチ修正された icc 7.1 によってそれが可能になっている。 icc でコンパイルされたカーネルで NFS が動かないとか、 IP がこわれているとか、いくつかのバグが残っている。 コンパイル環境の整備ができたら、この分野に詳しい 人たちが、これらの問題を解決してくれるだろう。カーネルが動けば、 次はユーザランドである。一通りうまくいけば、このバイナリが配布できる であろう。 利点は以下の通りである。コンパイラからのエラーメッセージが違うため、 ソースデバッグのヒントとして役立つ。ソースの移植性が高くなる。P4 により最適化された コードになる。(gcc はこの分野でいくつかの弱点がある。)
FreeBSD に icc を移植し、それによって FreeBSD を再構築している。現在、 パッチ修正された icc 7.1 によってそれが可能になっている。 icc でコンパイルされたカーネルで NFS が動かないとか、 IP がこわれているとか、いくつかのバグが残っている。 コンパイル環境の整備ができたら、この分野に詳しい 人たちが、これらの問題を解決してくれるだろう。カーネルが動けば、 次はユーザランドである。一通りうまくいけば、このバイナリが配布できる であろう。
利点は以下の通りである。コンパイラからのエラーメッセージが違うため、 ソースデバッグのヒントとして役立つ。ソースの移植性が高くなる。P4 により最適化された コードになる。(gcc はこの分野でいくつかの弱点がある。)
とのことなので、FreeBSDの中の世間一般の人も頑張っているのですよ。
速度は余り問題にならなさそうなところではなく、速度が重要視されるアプリにおいて「世間一般の人が」いまいちな対応しかしてないところがやだなー、といいたかったんですが舌足らずでしたねすいません。
個人的にはエラーメッセージなり警告なりが云々、というのはどっちかというとlintでも使えよという気がしないでもないです。
ものすごく素朴な疑問なんですが、iccでカーネル作ってうれしいのでしょうか…?いやもちろん技術的には面白いのはわかるのですが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
コンパイラを変えてカーネルを作る意味 (スコア: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 による性能向上が期待できるのであれば、ポータビリティ向上の努力は世のためになるのでは?