intel compiler for Linux
■ このスレッドは過去ログ倉庫に格納されています
0001login:Penguin
01/11/29 17:53ID:5k7yf0aiintel 社の Web ページ
URL:<http://developer.intel.com/software/products/eval/>
の、"Non-Commercial Unsupported Software(非商用、サポート無し)" から、
RedHat系Linux 6.2 または 7.1 に対応した IA-32 や IA-64向きの
最適化C++,Fortran9x用のコンパイラ(version 5.0.1) が無料で
ダウンロードできるようになっています。
(詳しいライセンス条件は、ダウンロード時に表示される文書を
参照してください。)
intel 自身が作ってますので、インテル系のCPUの資源を活用できる
実行ファイルが生成されるます。(AMD の Athlon も Pentium III と
みなしてコンパイルオプションを選べばMMX機能などを使うことが可能です。)
以下は、「無料永続版」を入手した後で、それを実際に使えるようにする
ための設定方法の記述です。
C++ と fortran9x を両方ともインストールする例を書いていますが、
どちらかだけしか必要ない場合は、片方を省略することができます。
例は RedHat6.2 系統向けになっていますが、7.x 向けの場合でも大体同様です。
(Web ページからダウンロードしてくるファイルが違うだけです。)
ダウンロードする際に入力したメールアドレスにインストール時に必要となる
ライセンスキー情報が送られてきます。
0082login:Penguin
02/01/22 01:09ID:bDfE+epr明日ifcで試してみよう。
(((( ;゚Д゚)))ガクガクブルブル
0083login:Penguin
02/01/22 20:53ID:wJXZKWBHたぶんこれはIFCでは直ってるはず。
というかアセンブラのソース見るわ。
なんだかあおってすまん。
0084
02/01/29 23:03ID:PECJA2Mi0085login:Penguin
02/02/03 18:11ID:lkEkFcBp知らなかった。
0086login:Penguin
02/02/04 21:30ID:B2i7yVMDすぐ Internal error が起こる。cast がうまくいかんことないか?
integer*8 で I=iargc() が変な値が返ってくる。
call exitで出られないことはないか(c の wrapperを書きました)。
あーGNUに統合しやがれ!
0087
02/02/08 17:20ID:sam3w5OZCPUは何を使っているの?
0088login:Penguin
02/02/08 19:01ID:MfBFWerpiargcはInteger*4を仮定するのです。
0089
02/02/10 13:05ID:f9cX/woZ結果がめちゃくちゃ。まああたりまえだけどね。
0090
02/02/13 23:45ID:8/27EbsIじゃないのかが不安だ。将来は無料版はなくなるのではないか?
0091login:Penguin
02/02/14 08:21ID:qBCCIPAvええんとちゃうか。出来ればGNUに統合されて欲しい。
0092
02/02/16 01:17ID:P37gR3ZU0093名無しさん@Emacs
02/02/17 07:24ID:PId1GyBhそれで失う利益よりもPentiumの売上が増える効果のほうが大きければ、
ビジネスとして正しい選択技でしょ。
0094名無しさん@XEmacs
02/02/18 01:58ID:iYWvirB6Intelに正座して聞かせたい
0095login:Penguin
02/02/18 12:42ID:X/HQdXYCそのうち g++,g77 が icc, ifc より高速になるYO!
0096login:Penguin
02/02/19 10:30ID:ygRZQp1y確認した。gaussian でかけているのはCのサポート関数の
おかげ。
Program FileO
Real*8 X(16*1024*1024)
do i=1, 16*1024*1024
X(i)=1.0D0
end do
open(1,File='fileout.data',status='unknown',
1 form='unformatted')
write(6,*)'Open OK--->fileout.data'
do i=1,1024
if(mod(i,10).eq.0) write(6,*)i
write(1)X
end do
end
Input/Output Error 161: Write operation failed
In Procedure: main program
At Line: 11
Statement: Unformatted WRITE
Unit: 1
Connected To: fileout.data
Form: Unformatted
Access: Sequential
Records Read : 0
Records Written: 15
End of diagnostics
ちなみにgccだとgcc-3.1(experimental,2002-2-2)
は少なくともそうはならない(FreeBSDで確認)。
0097login:Penguin
02/02/19 13:18ID:wHR25Yfq正直、それは無理じゃね?
0098login:Penguin
02/03/08 09:38ID:0oVxicVH0099login:Penguin
02/03/16 20:17ID:jeTKf9Otいつになるかわからんけど。
0100login:Penguin
02/03/17 16:27ID:Y0L5kwur4月はじめには正式版出荷。
0101login:Penguin
02/04/01 23:00ID:MIY3lWi0というわけで4/1にはりこんでみたがまだだった(当然か)。
0102login:Penguin
02/04/01 23:56ID:4KjWNtlY最適化とかにはあんまこだわってないのか?
0103名無しさん@お腹いっぱい。
02/04/02 00:41ID:BCv0vzPu0104login:Penguin
02/04/02 01:21ID:uU1FqcA5ふつーに「カナディアンクロスコンパイル」できるのって、gccくらい
でわ?
# XってプラットホームでYで動くZ用クロスコンパイラ作ることね
# <カナディアンクロス
# Linuxで、MinGW/gccコンパイルして、Winのダイアログをコンパイル
# できたときは、ちょっと感動した。(カナディアンじゃないけど)
どこぞで、「おかげでプロセッサに特化した最適化は遅れがち」って
書いてあったぞ。まぁ、だからegcsとかも出てきたり。
でも、「とりあえず、gccは動くだろ」って安心感は、デカイよな。
HP-UXをたまに使うから、つくづく思う。
そーいや、「WindowsでLinuxカーネルコンパイル」とかも理屈上は
できるハズだな。だれか挑戦しない?
0105login:Penguin
02/04/02 14:46ID:j7gY85GQプロレス技みたいだな。なぜカナダ?
0106login:Penguin
02/04/02 22:10ID:qqpoU7Yoなる方向になる。とするとGCCが最低レベルのコンパイラになるよな。
# GCCにはコンパイル速度のほうをもっと頑張ってほしい。インライン関数と
# かテンプレートとかたくさん使うと使うとやってられない。
0107名無しさん@お腹いっぱい。
02/04/02 23:23ID:BCv0vzPu全てのコンパイラを全順序に押し込むわけ?
0108login:Penguin
02/04/03 00:51ID:aLlZ/CTX「『カナディアンクロス』の名前は、3つの異なる種類のシステムが
つかわれているような、最も複雑なケースに由来しています。その
ような問題が顕在かしてきた当時、カナダには3つの国民政党があった
ので、このように呼ばれることになりました。」
だそーだ。cygnus用語かな?
0109login:Penguin
02/04/03 05:21ID:2DUVTyBBifcで-O2 -tpp7とかやってみ。g77の数倍は時間かかるぞ。
0110login:Penguin
02/04/03 23:15ID:FRqVmuPz失敗しとるヤシがいる。
# http://pc.2ch.net/test/read.cgi/unix/1012057979/l50
Liunx+icc で mozilla をコンパイルした人いる?
0111login:Penguin
02/04/04 00:16ID:b5ogLD4jなぜかプリプロセッサがビミョーにちがうのか、エラーになってしまう
(昔のことだから、メッセージ残ってないしスマソ)
あとオプション変える必要あったりな。
-fPICは-kpicに、-Wl,rpathは知らんのでリンクだけはgccで...
でも前述のエラーとかでできなかった(へたれ)
0112login:Penguin
02/04/04 01:45ID:b8zl9fsb0113login:Penguin
02/04/19 01:13ID:c5m+sLvDマチクタビレタ〜
☆ チン 〃 Λ_Λ / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
ヽ ___\(\・∀・) < 早くしてよね > 6.0
\_/⊂ ⊂_ ) \_____________
/ ̄ ̄ ̄ ̄ ̄ ̄ /|
| ̄ ̄ ̄ ̄ ̄ ̄ ̄| |
0114login:Penguin
02/04/25 13:03ID:s0tjalkGでてるぜ!
check it out!!!
0115
02/04/25 16:54ID:hRAttTY0(サポートなしの無料版)は、Fortran も
C++ も、バージョン6.0はダウンロードできないよ。ダウンロード
するリンク自体がいくらさがして発見できない。
(Web でユーザー登録とかをしてみてもだめ)
0116login:Penguin
02/04/25 17:20ID:s0tjalkGweb で登録した後、メールは来た? そこにURLかいてあるよ。
http://developer.intel.com/software/products/compilers/downloads/l_fc_p_6.0.140.htm
0117login:Penguin
02/04/26 11:09ID:ybIjNGS+http://developer.intel.com/software/products/compilers/downloads/l_cc_p_6.0.139.htm
だよ。
0118login:Penguin
02/04/26 11:52ID:pSUh8qyn01196.0のインストール法
02/04/26 12:38ID:ybIjNGS+るライセンスファイルを入手し、バイナリもダウンロードし,入手してあると
する。(カーネルのバージョンなどによっては、だめな場合がありうるので対
応を確認しよう。)以下はインテルのC++とF90を両方入れる場合の説明に
なっている。
その1) 作業場所(以下の説明で$WORKとしよう)を用意して、そこに
l_cc_p_6.0.139.tar l_fc_p_6.0.140.tar を入れる。
展開するための場所を$WORKのしたに作る。
# mkdir l_cc_p_6.0 ; mkdir l_fc_p_6.0
tar アーカイブ を,それぞれの下で展開する。
# (cd l_cc_p_6.0; tar xvf ../l_cc_p_6.0.139.tar )
# (cd l_fc_p_6.0; tar xvf ../l_fc_p_6.0.140.tar )
それぞれの下でインストールスクリプトを実行する。
# (cd l_cc_p_6.0; ./install )
# (cd l_fc_p_6.0; ./install )
それぞれのインストールスクリプトでの応対を適切にする。
IAー32かどうかの撰択、コンパイラとデバッガのどちらを入れるか。
(どちらを先に入れても問題ない。どうせあとでもどってくる。)
いろいろと答えていくが、/opt/intel 以下が標準インストール場所
らしいので、特にそれでも問題なければ、それをそのまま撰ぶ。
rpm のインストールオプションも同様。
コンパイラとデバッガを各々入れたらOK。
(途中でKTERMの画面の標示の白黒反転が狂うのが欝。)
その2) ディレクトリー /opt/intel/licenses/ に、メールに添附されてきた
ライセンスファイルをコピーする。(xxxxxxxx,yyyyyyyy は数字)
# cp l_cpp_xxxxxxxx.lic /opt/intel/licenses
# cp l_for_yyyyyyyy.lic /opt/intel/licenses
その3) $HOME/.bashrc にコマンドサーチパスを追加するためにつぎの行を加える。
---------------
PATH=$PATH:/opt/intel/compiler60/ia32/bin ; export PATH
---------------
上の設定をすぐにいかしたいときは
# source ~/.bashrc
としておく。
INTEL FORTRAN を使う場合には、シェアードライブラリーを実行時にリンクするために、
----------------
LD_RUN_PATH=/opt/intel/compiler60/ia32/lib ; export LD_RUN_PATH
----------------
も付け加えておく。上の設定をすぐにいかしたいときは
# source ~/.bashrc
としておく。あるいは、/etc/ld.so.conf に一行
/opt/intel/compiler60/ia32/lib
を追加し、 設定をすぐに生かしたいなら
# /sbin/ldconfig
を実行しておく。
その4) コンパイラがうごくかどうかは、
# icc a.c; ./a.out
# ifc a.f; ./a.out
などにより確かめること。
# icc -help
# ifc -help
などにより、簡単な使い方が分かる。
以上終り)
0120login:Penguin
02/04/26 14:45ID:9G9h10f60121login:Penguin
02/04/27 13:16ID:l7/+TGKwどうも情報、ありがとうございます。てなわけで
取りに行こうとしたんですが、
https://shale.intel.com/registrationcenter/register.asp
が落ちているのか、つながりませんのでライセンスファイルを
もらえなくて欲求不満です。
それと、みなさん、pgplotってライブラリ、使ってます?
なんかifcだとうまくコンパイルできないんですが。
0122login:Penguin
02/05/09 00:58ID:mt4hx9Cg超亀レスだが、alienパッケージを入れたあとに普通にinstallスクリプトで
インストールってことが5.0では出来たんだけど、6,0では出来なくなっている?
0123login:Penguin
02/05/09 18:28ID:usKCh3+Y速くなっているの?
0124login:Penguin
02/05/10 00:38ID:S+u2Lx1oないみたいね、ここ読んだ限りでは。NDA 問題ないから速いかと思ったのに。
そのうち気が向いたらにしよっと。
0125login:Penguin
02/05/10 06:52ID:AeDox/td君がどんな計算しているのかちょっとわからないけど、
僕の環境ではPentiumIII@1GでAlpha 21264@500MHzとだいたい
同じパフォーマンスだったよ。Pentium4@2Gならもっと高速です。
僕らはpentium4は持ってませんが。また使ってみてください。
数値計算はチューニングが必須です。
0126login:Penguin
02/05/10 07:59ID:p++nUXag5.0なら問題ないんですけど、6.0の場合はpotatoのRPMのバージョンが
古すぎるのでalienすらできないですね。
d-uに困ってた人居ましたけど、woodyへdist-upgrade必須ではないかと。
>>125
うちの計算もそんな感じです。ほとんどFFTでできてるようなプログラムです。
あと6.0の目玉機能は自動並列化だと思ってたんですが、試す環境にないのが
非常に残念。
0127login:Penguin
02/05/10 09:30ID:up11SU+xパフォーマンスが得られる場合があるだろう。ダウンロード
してみたらどう?
0128124
02/05/10 09:32ID:S+u2Lx1o今までgccでintelも使ってたけど、alphaには全く太刀打ちできなかった。
けどその話聞くと結構速いみたいね。またintel純正のコンパイラーで
がんばってみるか。
0129login:Penguin
02/05/13 11:23ID:9l4vLaBHこれはMKLのことですか。BlasとLapackを配布していますが、
PentiumIIIではMKLが少し高速です。しかし、Pentium4では
atlasが高速でした。Lapackはよく知りません。
>>128
メモリのバンド幅はあげたほうがいいでしょう。
0130plamoユーザ
02/05/13 11:45ID:c5nvN02Zslackwareとかplamoのような非rpmなディストリビューションで動かしている
方いらっしゃいますか?
0131login:Penguin
02/05/13 12:33ID:YDaaODKgSlackやPlamoにrpmコマンドを入れればよかろうが。
ゴルァ!
0132plamoユーザ
02/05/13 13:18ID:c5nvN02Zそりゃそーなんだけどね。rpm-2.5.1をいれたら「これじゃ旧い」って
怒られるし、rpm-4.0を入れようとしたらライブラリが足らんって言われて
コンパイル通らんし。で、他に方法無いんかなと思って。
地道にやります。失礼しました。
0133login:Penguin
02/05/13 13:28ID:9l4vLaBH使って展開していますね。
0134plamoユーザ
02/05/13 18:05ID:c5nvN02Zお蔭様で、あっさり動きました。快適です。
有難うございました。
0135
02/05/14 01:52ID:IZxJRGukRDRAMのものを買うべし、買うべし。
0136正直alphaの大メモリ機は高スギ
02/05/14 04:21ID:XDFbjSgqxeonマシンだとメモリ8Gとか16G積んでる奴ありますよね。
32bitマシンだと2Gだか4Gだかにメモリの壁があるとどこかで聞いた
覚えがあるのですが、このメモリは単一の計算でめいっぱい使いきれる
のでしょうか?
普通に巨大計算できるのか、並列化しないとできないのかご存知の方
いらっしゃいません?
ちなみにifc6.0用のdebianパッケージがここに置いてありました。
http://www.gfd-dennou.org/arch/cc-env/ifc/
0137login:Penguin
02/05/14 05:13ID:XO5C21R+Pentium Pro以降のCPUにはPAEというアドレス変換機構がついて
いるので、64GBまでは扱えます。ただし、チップセットの制限に
引きずられますが。あと、変換のオーバヘッドがあるので、
パフォーマンスも悪化します。
Linuxでもこの機能はサポートされてます。
たぶん単一の計算でめいっぱい確保できるでしょう。
0138login:Penguin
02/05/14 05:47ID:XDFbjSgqできるのですね。参考になりました。
0139login:Penguin
02/05/14 06:10ID:XO5C21R+0140login:Penguin
02/05/15 05:38ID:gSF91Ka8大規模計算をやっている人ならばFortranな人が多いと思います。
sizeof(integer)=8 でないと困るように思いますが、ifcはPentium4
SSE2で64bit integer扱えるはずですが、-tpp7でも
でもそういうコードは吐かなかったです。僕が間違えた可能性は
高いですが。
AMDのx64や、Intel も IA-64 以外にもPentiumの64bit
拡張を考えているようですね。
ではでは。
0141login:Penguin
02/05/16 05:17ID:GYM8ysqy作動しましたが、どうやら6.0からは、Athlon上のLinuxでは
コンパイラが動きません。セグメントエラーなどが起きる。
0142login:Penguin
02/05/16 06:41ID:5yZwyBjV0143login:Penguin
02/05/19 22:26ID:TA85Te6Iおかしいなと思っていたら、本日マシンはお亡くなりになって
しまいました。M.B.か、CPUがいかれていて、BIOS画面すら起動
しなくなってしまった。
0144login:Penguin
02/05/23 01:52ID:MUEwqJ2Xにあるようです。expやsin,cosはgccの10倍以上の速度でした。
しかし、ベクトル化はコンパイラの条件が厳しくてほとんどされないし、
されても加速は2倍行かないですね。やっぱり、ベクトル型スパコンとは
違うんだと思いました。
0145
02/05/24 02:38ID:8A5lq9k5コードがでますかね。
0146login:Penguin
02/05/25 19:50ID:7ZkaIBTbにわかには信じられん。exp, sin, cos は数値演算プロセッサに渡している
だけだと考えられる。gcc側はへんなライブラリをかませているのか?
0147
02/05/26 02:34ID:7Wq7WMObいたりするのかもね。パイプライン化に最適なコードを出しているのが
効くのかも。インテルのMATHライブラリーはすごく最適化していると
思う。
0148login:Penguin
02/05/26 06:59ID:yJVR8li1なるほど!
0149login:Penguin
02/05/26 10:25ID:yJVR8li1やっぱりよーわからん。多分インライン展開はgccでもやっとると思うが。
あー頭イテ。
0150login:Penguin
02/05/26 10:28ID:4fUXbWUZコプロの命令は死ぬ程おそいんだYO
0151名無しさん@お腹いっぱい。
02/05/26 11:49ID:ALTTjrt30152login:Penguin
02/05/26 14:04ID:kDtJ2VZ7> (途中でKTERMの画面の標示の白黒反転が狂うのが欝。)
Vineのftpに解決法が載っていたような。moreがどうとか…
rxvtとかではならんらしいです。
0153名無しさん@お腹いっぱい。
02/05/26 19:53ID:ALTTjrt3file:///usr/share/doc/xterm/xterm.faq.html#xterm_hiliteより、
Reverse video is not reset
When running less or other programs that do highlighting, you see the
highlighting not turned off properly.
This may be due to incompatible terminal descriptions for xterm. With XFree86
3.2, I modified the terminal description for XFree86 xterm to use the VT220
(aka ISO 6429) controls that allow an application to turn off highlighting (or
bold, underline) without modifying the other attributes. The X Consortium xterm
does not recognize these controls.
If, for example, you are running an older xterm and rlogin to a system where
the newer xterm has been installed, you will have this problem, because both
programs default to $TERM set to xterm. The solution for mixed systems is to
install the newer terminal description as as a different name (e.g.,
xterm-color) and set the termName resource accordingly in the app-defaults file
for the system which has the newer xterm.
続きに、「What $TERM should I use?」つーのがあって、
xtermの場合、xterm-xfree86ってのを使えってさ。
0154login:Penguin
02/05/27 17:17ID:W/KwZtKCやってみたところで結果が理解できない自分を発見しますた
0155login:Penguin
02/05/27 22:12ID:UHJ+0bj9#include <stdio.h>
#include <math.h>
main()
{
printf("%d\n",sin(3.14));
}
gcc-2.95.3だったら(FreeBSDだけど)、
main:
pushl %ebp
movl %esp,%ebp
subl $8,%esp
addl $-4,%esp
addl $-8,%esp
pushl .LC2+4
pushl .LC2
call sin
subl $8,%esp
fstpl (%esp)
pushl $.LC1
call printf
leave
ret
こんなコードを出しよる。
icc だと、
main:
.B1.1: # Preds .B1.0
pushl %ebp #5.1
movl %esp, %ebp #5.1
subl $3, %esp #5.1
andl $-8, %esp #5.1
addl $4, %esp #5.1
subl $16, %esp #5.1
fldl _2il0floatpacket.1 #6.17
fsin #6.17
movl $__STRING.0, (%esp) #6.17
fstpl 4(%esp) #6.17
call printf #6.17
# LOE ebx esi edi
.B1.2: # Preds .B1.1
xorl %eax, %eax #7.1
addl $16, %esp #7.1
movl %ebp, %esp #7.1
popl %ebp #7.1
ret #7.1
.align 4,0x90
そのままコプロをよびだすようなコードやね。
gcc はライブラリをはさむな。実際ライブラリのソースを
見るともうちょっと処理をしている。10倍はわからんが、
差はでるやろうな。
0156login:Penguin
02/05/27 22:13ID:UHJ+0bj9って笑うコードだな。すまん。間違えた。
0157login:Penguin
02/05/28 00:02ID:I7J1z0a7>>155
うちの環境は、Linux + glibc2.1 + gcc2.95.2。
/usr/include/math.hを追っていくと、/usr/include/bits/mathinline.hってのがある。
んで、どーも/usr/include/feature.hが-Oオプションを監視していて、
つけてると、リンク時にインライン展開してくれるみたいなんだなー。
で、-ffast-mathすると、nmの出力からsinが消える。
~/test$ gcc -O m.c -lm
~/test$ nm -a a.out |grep sin
08048420 T __sin
08048420 W sin
~/test$ gcc -O2 -ffast-math m.c -lm
~/test$ nm -a a.out |grep sin
憶測だけど、--fast-mathを指定しないと、全ての関数をとりあえず
wrapしてしまって、インラインアセンブラコードまでは展開されないって
可能性はないかな?
例の数倍の差が出たって人、-ffast-math使って追試きぼーん。
0158名無しさん@お腹いっぱい。
02/05/28 01:10ID:fjbf3+Jg0159144
02/05/28 02:05ID:MAw0QlwZ#time a.out
2.600u 0.030s 0:02.63 100.0% 0+0k 0+0io 145pf+0w
#gcc -O3 -ffast-math test.c
#time a.out
9.650u 0.020s 0:09.68 99.8% 0+0k 0+0io 86pf+0w
#gcc -O3 test.c -lm
#time a.out
11.210u 0.020s 0:11.25 99.8% 0+0k 0+0io 97pf+0w
#gcc --version
2.95.2
10倍は気のせいだったのか、再現できませんでした。すいません。
-ffast-mathなしで4.3倍、-ffast-mathからは3.7倍です。
test.cではsinを10^8回計算してます。
>>158
debuggerはldbです。
0160login:Penguin
02/05/28 02:19ID:bUBmd7+C結果さんきう。
まだ3,7倍かぁ。
> test.cではsinを10^8回計算してます。
じゃ、-funroll-loopsと-frerun-cse-after-loopもきぼーんぬ
ところで、-m686とか使っても変化なし?って
> #gcc --version
>2.95.2
かぁ。これってpentiumへの最適化もされないよね、たしか?
0161login:Penguin
02/05/28 02:23ID:bUBmd7+Cできれば、テストしたソースもきぼーんぬ。
0162login:Penguin
02/05/28 08:44ID:t5QZ3SAT-ffast-math すると確かにLinuxでは
main:
fldl .LC33
pushl %ebp
movl %esp,%ebp
subl $8,%esp
addl $-4,%esp
#APP
fsin
#NO_APP
subl $8,%esp
fstpl (%esp)
pushl $.LC34
call printf
movl %ebp,%esp
popl %ebp
ret
となって実際にfsinを直接呼ぶね。
FreeBSDで同様の事(-ffast-math)をしても、call sin は取れなかった。
うげーーー。
#APP ってなんだろ。
#NO_APP
0163
02/05/28 08:59ID:w0d6+dv2どうやってインストールすればよいのか、詳細希望します。
できれば最新の4.5Rで。
0164名無しさん@お腹いっぱい。
02/05/28 10:16ID:fjbf3+Jg> #APP ってなんだろ。
> #NO_APP
Assembler PreProcessor.
asm文使うと挿入されます。
#NO_APP
asm文のコード
#APP
逆だから、optimize optionやdebug optionや付けるlibraryで、
fsinの実体が変わったりするのかね。
0165login:Penguin
02/05/28 14:55ID:aPvGsWSrちっとむつかしい。あんまりおすすめしない。
icc はlinux_base-7を入れなければならないが、
FreeBSD ネイティブバイナリを生成する。すばらしい!!
C++はコンパイルできないみたい?
ifc はまだsend-prしたばかり。FreeBSDネイティブバイナリ
作成はむつかしいと思う。
4.5-Rだと入らない。icc は 5.0 なので、もう手に入らない。
ports を cvsup すれば入る。
わからなかったら 4.6-Release まで待つべし。
そこまで解説する情熱がもてない。すまん。
>>162
ありがとうございました。
さっきfreebsd-users で
話してたのですが、FreeBSD(4.6-RC, gcc-2.95.3 buildin)
でも
-O -ffast-math -mfancy-math-387
ってやれば、fsin を出していることがわかりました。
0166login:Penguin
02/05/28 22:52ID:lr8zx0zzhttp://home.jp.freebsd.org/cgi-bin/showmail/FreeBSD-users-jp/68752
http://home.jp.freebsd.org/cgi-bin/showmail/FreeBSD-users-jp/68753
http://home.jp.freebsd.org/cgi-bin/showmail/FreeBSD-users-jp/68755
http://home.jp.freebsd.org/cgi-bin/showmail/FreeBSD-users-jp/68758
http://home.jp.freebsd.org/cgi-bin/showmail/FreeBSD-users-jp/68759
http://home.jp.freebsd.org/cgi-bin/showmail/FreeBSD-users-jp/68766
http://home.jp.freebsd.org/cgi-bin/showmail/FreeBSD-users-jp/68770
0167144
02/05/29 08:15ID:aVv8ARHZ#include <math.h>
#define N 1000*1000
main()
{
int i, j;
double *a = (double*)malloc (sizeof(double) * N);
double *c = (double*)malloc (sizeof(double) * N);
for (i = 0; i < N; i++)
a[i] = 1.0 * i;
for (j = 0; j < 100; j++)
for (i = 0; i < N; i++)
c[i] = sin(a[i]);
}
-mpentiumpro -funroll-loops -frerun-cse-after-loop効果なしです。
~
0168login:Penguin
02/05/29 11:33ID:D7OquwsK多分、インテルコンパイラは、外側のループ無くなってるな...
0169login:Penguin
02/05/29 11:36ID:D7OquwsK0170login:Penguin
02/05/29 14:30ID:gGpH3Xszに対して約9倍となりました。ただし、expだとoverflowするので、a[i]=1.0/(i+1)としています。
gccのexpはあまり最適化されていないようです。
>>168
>>169
繰り返し数に対しても配列の大きさに対しても、計算時間は線形に増加します。
また、ループの中外を入れ替えても結果は変わりません。
0171login:Penguin
02/05/30 11:27ID:Q1DeRRtzほんとかなと思ってためしてみました。
malloc をよばないようにして。
#include <math.h>
#define N 1000*1000
main()
{
double a[N];
double c[N];
int i, j;
for (i = 0; i < N; i++)
a[i] = 1.0 * i;
for (j = 0; j < 100; j++)
for (i = 0; i < N; i++)
c[i] = sin(a[i]);
}
当方Celeron800ですが、
icc -O3 -tpp6 -xiMK -S test1.c
でこんぱいるすると、fsinが一つも入っていないぞ!
つーか、コードを見ると最後の二重ループはまわってさえいない。
gcc -mpentiumpro -O3 -ffast-math -mfancy-math-387 test1.c
でのコードは素直だ。ちゃんと fsin を使っているし、普通に
アセンブラに出力されている。
つーわけで、参考にならん。
まぁそりゃそうだ。というのもこのコードを最適化すると出力が
全くないから
#include<stdio.h>
main(){}
と等価だもんな...
0172login:Penguin
02/05/30 11:32ID:Q1DeRRtz#include <stdio.h>
#include <math.h>
#define N 1000*1000
main()
{
double a[N];
double ans;
int i, j;
for (i = 0; i < N; i++)
a[i] = 1.0 * i;
for (j = 0; j < 100; j++)
for (i = 0; i < N; i++)
ans = +sin(a[i]);
printf ("%lf\n",ans);
}
% icc -O3 -tpp6 -xiMK test1.c
% time ./a.out
-0.977352
14.926u 0.007s 0:15.41 96.8% 5+10175k 0+0io 0pf+0w
% gcc -mpentiumpro -O3 -ffast-math -mfancy-math-387 test1.c
% time ./a.out
-0.977352
15.089u 0.007s 0:15.15 99.5% 5+10193k 0+0io 0pf+0w
%
というわけで、誤差範囲。
もっと本質的なコードが必要だな...
0173login:Penguin
02/05/30 11:42ID:Q1DeRRtz% gcc -mpentiumpro -O3 -ffast-math -mfancy-math-387 test1.c
% time ./a.out
-0.977352
15.095u 0.007s 0:15.15 99.6% 5+10187k 0+0io 0pf+0w
% gcc -funroll-loops -mpentiumpro -O3 -ffast-math -mfancy-math-387 test1.c
% time ./a.out
-0.977352
2.355u 0.023s 0:02.39 99.1% 5+10184k 0+0io 0pf+0w
ま、こだわってもしゃあないな...
アセンブラのソースを見ると、二つ目のループは
unroll されてない。つーことは律速は 1コ目のループか。
でも、icc に勝ったぜ!
(またミスった。ans を初期化していないや。すまん)
0174login:Penguin
02/05/30 11:47ID:Q1DeRRtzあまり意味無いことを書きました。ごめんなさい。
朝飯ぬいたので血糖値が低いみたいです。
#include <stdio.h>
#include <math.h>
#define N 1000*1000
main()
{
double a[N];
double ans;
int i, j;
ans=0.0;
for (i = 0; i < N; i++)
a[i] = 1.0 * i;
for (j = 0; j < 100; j++)
for (i = 0; i < N; i++)
ans = ans + sin(a[i]);
printf ("%lf\n",ans);
}
で試した。
% icc -O3 -tpp6 -xiMK test1.c
% time ./a.out
23.288398
15.070u 0.015s 0:15.95 94.5% 5+10209k 0+0io 0pf+0w
% gcc -funroll-loops -mpentiumpro -O3 -ffast-math -mfancy-math-387 test1.c
% time ./a.out
23.288398
14.811u 0.000s 0:14.98 98.8% 5+10197k 0+0io 0pf+0w
% gcc -mpentiumpro -O3 -ffast-math -mfancy-math-387 test1.c
% time ./a.out
23.288398
15.067u 0.000s 0:15.16 99.3% 5+10180k 0+0io 0pf+0w
0175login:Penguin
02/05/30 11:53ID:Q1DeRRtzまあそんなに変わらないでしょう。
icc は 二重ループをunrollしなかった。gcc は -funroll-loops
を付けると二重ループも一部unrollする。
やはりもう少し本質的な例が必要だと思う。
0176login:Penguin
02/05/30 12:04ID:Q1DeRRtzなぜ線形に変化しているかと言うと、icc では 君のプログラムの場合
一つ目のループしかまわらないようなコードを出力し、
そして二つ目の(二重ループ)は消えるのだ。ということで
一つ目のループはまじめに実行するから線形に変化するのである。
僕が試した場合はexpでも同じ結果だった。つまりexpは計算されていない。
僕がprintfをはさんだのはそういう理由による。
また、僕のans = +sin(a[i]); はダメだ。かしこいオプティマイザ
だと最後の値だけ計算して終りだろう。
0177login:Penguin
02/05/30 14:18ID:EoS08NAY> やはりもう少し本質的な例が必要だと思う。
総合的な評価と、個々の部分の振る舞いの究明をわけて考える必要があるが、
後者の方が計算時間餓鬼には有益だと思うから、今の流れでいいんと違う?
0178login:Penguin
02/05/31 09:33ID:a8/cq5U3>一つ目のループしかまわらないようなコードを出力し、
>そして二つ目の(二重ループ)は消えるのだ。
私も、気になっていたから、ループ数と時間の関係を調べたけど、
内ループ数にも外ループ数にも計算時間は比例したけど?あと、
2つ目のループが回らないのなら、sinとexpで時間が変わるか?
言ってる事の意味が良くわかりません。
iccのmathが速いのは、SIMDバージョンのsin,exp等のためです。
従って、-axW -xWでかつP4上でないとgccと大きな差はでません。
0179login:Penguin
02/05/31 17:04ID:25Um11/Kうーーーむ。なんと言ったらいいのかなぁ。
アセンブラの出力は読んだかな?
気になったから君のコードをコピペして、コンパイルして、
アセンブラの出力を読んでみたんだよ。
そうしたら iccの場合、fsin って行が消えてたよ。
つまり計算していないんだな。gccはまともに計算してたヨ。
あとね、君のコードだとね、賢いコンパイラの場合、最悪空の
コードをはくわけ。これではコンパイラの性能を見ているとは言えないよね。
だから君のベンチでは結論出ないわけ。だから僕はやり直したんだよ。
僕は-tpp6な環境なので実行はできんです。それといまちょっと
システム入れ替え中なんで試せないんだ。ごめんね。
よかったら -tpp7の場合 のソースの
出力良かったら見せてね(icc -xW -tpp7 -S test.cで test.s が出来る)。
SIMDの出力も見たいし。
10倍かぁ...それは魅力あるよ。
昔ね、integer*8 のコードを書いてtpp7オプションでコンパイル
してもどうしてもSSE2のコードが出なかったんだ。君の結果が
手がかりになるかもしれない。良かったら教えてちょうだい。
0180login:Penguin
02/05/31 17:19ID:Ki/fe8PFgccでもiccでもループが省略されていないことを確認しての比較だから
十分本質的だと思うけど?
>そして二つ目の(二重ループ)は消えるのだ。
配列がスタックのローカル変数ならループ省略の最適化も可能です。
あなたが、わざわざループが消えるように書き換えたということになります。
0181login:Penguin
02/05/31 17:46ID:25Um11/Kそんな気がしてきた。
0182login:Penguin
02/05/31 17:51ID:25Um11/Kアセンブラの出力を比較するってのはダメ?
■ このスレッドは過去ログ倉庫に格納されています