トップページ⇒linux
985コメント403KB

intel compiler for Linux

■ このスレッドは過去ログ倉庫に格納されています
0001login:Penguin01/11/29 17:53ID:5k7yf0ai

intel 社の 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 ページからダウンロードしてくるファイルが違うだけです。)

ダウンロードする際に入力したメールアドレスにインストール時に必要となる
ライセンスキー情報が送られてきます。
0052login:Penguin02/01/19 15:48ID:9hT/dXby
>>47
alignmentのリンク先、みました。2年位前に、
alpha 21264 + CFLAで行列計算をさせていたとき、
行列の大きさを大きめにとると、とたんに計算が
速くなったことがあり、不思議だなと
思ってたけど、このためかもしれませんね。
どうもありがとう。

しかしファイル名を1文字から8文字用意して
ベンチを取ってから走らせなきゃいけないのかあ。
00535002/01/19 15:51ID:umOrHyJq
失礼。pen3の場合今のところmklよりg77のほうが1.5倍速いです。

私も
>おかげでf90がただで手に入るようになったわけで
と言いたかったのですが…。
取り敢えず今まで通りvf90使っておきますか。

選択肢が増えたわけだからそれぞれの癖さえ掴めばいいのですかね。
0054login:Penguin02/01/19 17:03ID:/efnsvv4
>>
基本的に4bytesのアラインだからやねんな。
mallocで取られるcとはちがい、fortranの場合は
大きな配列をスタティックにとってというはなしになるから
結構致命的になると思う。sbrkなんか使うなよなぁ。
訳解らん。
>>53
RH7.1 のgccってそんなに高速なんだ。知らなかった。
HPCのページを見てると不当にg77の評価が低くて、
かなりむかついた。それ以来あそこのデータは信用したくない。
というか、チューニングなんてマニアがごりごりやったやつと
何も考えずに組んだやつだったらそりゃちがうだろう。
どうせチップとか作ってるわけじゃないのにえらそうに。
なんだか嫌なやつらだ。
ま、ベンチとってくれてありがとう、とは思うけど。
0055login:Penguin02/01/19 17:06ID:/efnsvv4
さらにg77も出てそんなに経っても無いのに。
あ、僕があおられているだけか。

ところでRHのBLASはコンパイルはそのままで
手は加わってないんだよね?なぜATLASより遅いんだろう?
あんまり知らないですが。知ってたら教えてください。

やっぱPenIVなんやろうな。
0056login:Penguin02/01/19 17:21ID:umOrHyJq
>>54
Vine-2.0に(おまけで)付いてた富士通のフォートランはそのころのg77より
ずっと速かった覚えがあるけど、>>51 ではg77が速いって言ってるから、
多分g77の性能が上がったんだと思う。
あとそのころでもgccと富士通のCコンパイラとは互角の性能出てた。

もちろん計算の種類にもよるだろけど。
0057login:Penguin02/01/19 20:42ID:T0M+fgYB
g77はgccのバージョンを
あげると急に速くなること
あるね。

p4のmklはSSE2に対応してる。
これとほぼ同じベンチを
red hat7.1についてくるblasが
たたき出す。自分でコンパイルした
blasはへたれ。>>55 さんは
自分でコンパイルしたのですか。
それとred hatは7.1っすか。

ppc2002でのカキコは疲れるな。
0058login:Penguin02/01/19 22:16ID:CcBGA9H/
ふーむ、RH7.1付属のBlasはどーやってコンパイルしたか
分かるのでしょうか? 僕は FreeBSD or make を
そのままするんでよくわからないんです。
フラグは? レファレンスインプリメンテーションのコンパイル?
ううううーむ。ちょっと信じられない。
分かる範囲でよろしければ教えていただくとうれしいです。
0059login:Penguin02/01/19 22:33ID:CcBGA9H/
やっぱ自分で調べた。
# rpm -ivh lapack-3.0-12.src.rpm
# cd /usr/src/redhat/SPECS/
# rpm -ba lapack.spec
でビルドするんやね。
コンパイルフラグは
-O2 -march=i386 -mcpu=i686 これだけか。
多くのパッチが当たっているがそんなに重要そうではない
感じがする。mkl と比較してそんなにスピードが出るのか。
不思議じゃ。研究が一段落したらifcでもやってみるわ。
lapackのパッチは参考にする。
0060login:Penguin02/01/19 22:41ID:CcBGA9H/
g77は
/usr/bin/g77 -v
g77 version 2.96 20000731 (Red Hat Linux 7.1 2.96-98) (from FSF-g77 version 0.5.26 20000731 (Red Hat Linux 7.1 2.96-98))
Driving: /usr/bin/g77 -v -c -xf77-version /dev/null -xnone
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)
GNU F77 version 2.96 20000731 (Red Hat Linux 7.1 2.96-98) (i386-redhat-linux) compiled by GNU C version 2.96 20000731 (Red Hat Linux 7.1 2.96-98).
GNU Fortran Front End version 0.5.26 20000731 (Red Hat Linux 7.1 2.96-98)
__G77_LIBF77_VERSION__: 0.5.26 20000731 (prerelease)
@(#)LIBF77 VERSION 19991115
__G77_LIBI77_VERSION__: 0.5.26 20000731 (prerelease)
@(#) LIBI77 VERSION pjw,dmg-mods 19991115
__G77_LIBU77_VERSION__: 0.5.26 20000731 (prerelease)
@(#) LIBU77 VERSION 19980709

こんな感じ。
0061login:Penguin02/01/19 22:51ID:1EgeSYjk
>>59
blasに秘密がある気がするんだが。
0062login:Penguin02/01/19 23:02ID:CcBGA9H/
どういう秘密?
バイナリでしか提供されていないわけないよね。
ソースを調べると、

# grep -i BLAS lapack-20010525.patch
diff -uNr LAPACK.orig/BLAS/TESTING/cblat2.f LAPACK/BLAS/TESTING/cblat2.f
--- LAPACK.orig/BLAS/TESTING/cblat2.f Thu Nov 4 14:23:26 1999
+++ LAPACK/BLAS/TESTING/cblat2.f Fri May 25 15:57:46 2001

こんなかんじだよ?ATLAS の Whaley はなぜこんなにがんばれる?
うおーなぜだー!死ぬ程しりたい。
ちょっと風呂入って来る。

0063login:Penguin02/01/19 23:11ID:umOrHyJq
>>62
>>61 はただ lapack が blas を呼んでいる程度の意味だと思うが。
0064login:Penguin02/01/19 23:14ID:X8kahLTF
ここはATLASスレですか?
0065login:Penguin02/01/19 23:19ID:umOrHyJq
いや、lapackスレ。
ちなみに >>30 >>32 は漏れ。ちょっと責任感じてみたり…。
最初の目的は有名どころのコードをmakeしてみてicc ifc の癖掴もうと思ってたんだが…
0066login:Penguin02/01/19 23:26ID:CcBGA9H/
まだ風呂にははいっておらぬ。
すまぬ。Intel Compiler スレだ。
しかしながら、icc, ifc は最適化に優れていると聞くが
どの程度なのかはコードの実行スピードを見ない限り分からないではないか。
とりあえず、BLAS, LAPACK は、数値計算ライブラリとして重要な
位置を占めておる。それらの最適化はそれこそ我々の飯の種なのだ。
ということで、ちとマニアックな話+ifc に関係ない話をするかも
しれないが、やはりifcの性能は気になっておるんだ。
まぁ結論はなかなか出ないと思うがきいてやっておくれ。
0067login:Penguin02/01/19 23:33ID:CcBGA9H/
さっきの srpm からのビルドのログを見ると

+ cp -f /usr/src/redhat/SOURCES/Makefile.blas BLAS/SRC/Makefile
+ cp -f /usr/src/redhat/SOURCES/Makefile.lapack SRC/Makefile
...
f77 -O2 -march=i386 -mcpu=i686 -c -o dgbmv.o dgbmv.f
f77 -O2 -march=i386 -mcpu=i686 -c -o dgemm.o dgemm.f
f77 -O2 -march=i386 -mcpu=i686 -c -o dgemv.o dgemv.f
...書き込み中: /usr/src/redhat/SRPMS/lapack-3.0-12.src.rpm
書き込み中: /usr/src/redhat/RPMS/i386/lapack-3.0-12.i386.rpm
書き込み中: /usr/src/redhat/RPMS/i386/blas-3.0-12.i386.rpm
書き込み中: /usr/src/redhat/RPMS/i386/blas-man-3.0-12.i386.rpm
書き込み中: /usr/src/redhat/RPMS/i386/lapack-man-3.0-12.i386.rpm

てな感じです。
たぶんblasはそのままだと思う。
006834=40=44=57=6102/01/19 23:51ID:pz4lxlEr
自分のプログラム(行列の積、Gram-Schmidtの直交化、対角化など)
では、redhatについてくる/usr/lib/libblas,liblapackを使ったのと、
自分でblas,lapackをコンパイルしたので、前者のほうがかなり
パフォーマンスがいい。それでもって、ifc+mklだと
/usr/lib/libblas,/usr/lib/liblapackを使ったのとおなじくらい。
ifc+mklはblas、lapackを最適化してるらしいので
(ttp://www.intel.com/software/products/mkl/mkl51w/mklspecs.htm)
redhatの/usr/lib/のblas,lapackもいい線いってると思ったんです。
前にも書いたけど、pen4 +rambus 512MB+redhat 7.1。
00696802/01/20 00:01ID:tTEZ7bJ8
>>67
そうですか。私のblas、lapackのmakeの
仕方が悪い(-march=i386 -mcpu=i686というオプションを
つけてないと思います)のかもしれませんね。
lapackを自分でmakeしたときnetlibの
汎用のを使いましたが、もっとintel系のlinuxに
適したものなのかな?
とりあえず、g77,pgfortran,ifcでやってみて一番
速いのを流すという方針がいいんですかね。
00706502/01/20 00:16ID:248hne5/
>>69
そですね。各コンパイラでコンパイルオプション適当に振って、
一番できのいいのを探して、それを使うのが結果として時間の
節約かも知れませんね。

ところで少し気になることは、ifcで、blasやlapackのように相当作り込まれ
たコードをコンパイルしてもそれほど効果無いようなのですが、自前の
ヘボコードなどをコンパイルすると2倍程高速化しているような気がします。

僕の場合はまず自分の腕を上げることのほうが先のようです…トホホ

0071login:Penguin02/01/20 00:25ID:5whqLm3T
風呂からあがってきました。
>>70
研究者の方ですか? そうやったら別にいいのでは。可読性のほうが
重要ですよ。二倍程度の高速化やったらコンパイラに任せた
ほうがいいかも知れませんよ。頭の体操にはいいかもしれませんが。
>>69
いろいろ流し直すのって面倒じゃないですか。だから噂程度で
ifc 万歳とか思ってたんですが、g77もがんばるわけですねぇ。
ううーむ。
00726902/01/20 08:43ID:K/B4TT8A
自分の計算は数カ月単位の
シミュレーションなんで、
結果がでてくる時間がオプション、
コンパイラで大分違うんです。
前にalpha 21264 で、手製の
lapack-blasをcxmlに変えたら
劇的に加速したこともあり、
以来、色々と試すことにしてます。
0073login:Penguin02/01/20 11:39ID:5whqLm3T
>>69
アラインメントは?
2ヵ月と4ヵ月では全然違いますよね。
00746902/01/20 13:32ID:0V/4SmC4
>>73
4月と2月で違うのって、
nelibのlapackですか。
もっと古いかも。そんなに
違うと思ってなかったんで、
無理に最新にしてなかった。
機能までアラインメントも気にして
なかったし。まだまだ、
やること、ありそうです。
0075login:Penguin02/01/20 15:33ID:5whqLm3T
>>74
すんません。数ヵ月単位のジョブと言うと2ヵ月が4
ヵ月というのが全然違うということです。
アラインメントは重要です。PentiumIVならもっと
違うかも知れません。Intel の compiler ならそういうのを
しれっとやりそうですが。
00767402/01/20 15:45ID:Zx6TOajk
>>75
ちゃんと2ヶ月、4ヶ月とかいてありましたね。
PDAから見てたもので、読み方が荒かったです。
もうしわけありません。

昨日、この板でアラインメンとを知って、
びっくりしてるところです。そういえば
思い当たるふしもあったので。それと、
今までのベンチマークは
time ./a_g77.out
time ./a_pgf77.out
time ./a_ifc_lapack.out
time ./a_cfla_O5.out
というようにコンパイラ、コンパイルオプション
ごとに、実行ファイル名を変えていたのですが、
これはまずいですね。月曜日から、いろいろと
することがありそうです。
00777602/01/20 16:12ID:Zx6TOajk
自宅からsshして試してみたところ、
g77,ifcはファイル名を変えても実行速度が
あまり変わりませんでしたが、pgfortran
は16%ほど、速いファイル名とそうでない
ファイル名と分類できてしまいました。
g77はf90に対応してないので、f90は
仕方なくpgf90でやってましたが、
これからはifc,pgf90の両方で試し、
かつ、ファイル名をいろいろと変えて
走らせることにします。
幸い、自分の今の計算は長い計算を
一回というのでなく、反復計算が
多いので、このファイル名を変えるというのが
実現可能です。
0078login:Penguin02/01/20 16:23ID:5whqLm3T
>>77
なんだか混乱させるようで悪いですけど。問題は
ファイル名だけではないのです。スタックのアラインメントの
問題だから、シェルの種類やもしかしたらコンディションで
変化するかも知れないのです。詳しくは僕も分かりませんが、
シェルが子プロセスを走らせるときのアラインメントが違えば
ファイル名だけで対処することはできません。
LinuxとFreeBSDだと微妙にアラインメントのブレは違うのですが、
これまた大きな問題です。Cの場合は適当にスタックを
変化させるように最初にいれておけば問題は無いですが、
Fortranの場合はどうしたらいいもんか?
いろいろがんばってみましたが、FreeBSDはカーネルパッチ
があって、なんとかコミットされたらと思いましたが
コミットされる前にページ毎消えちゃいました。

はぁー。
0079login:Penguin02/01/20 16:31ID:5whqLm3T
>>77
とりあえずこのスレの僕の書き込みでURL示してるのがあるので
ちょっと見てみてください。
0080login:Penguin02/01/20 17:31ID:C3Sbw68k
>>47のリンク先ですね。
実行するごとに微妙(0.2 秒)
くらい、実行時間が変わるのは
環境のためでしたか。
一つ分からないのですが、
ファイル名を1文字、2文字、、、、と
8通り作ると、pgfortでは実行
時間が15秒と18秒のものに
きれいに分かれるんです。
もちろん、コンマ1、2秒の
誤差はありますが。
g77, ifcでは10秒なので、
pgfortの最適化があまいのは
明らかなのですが。ちなみに
実行時間の測定は2回ずつ
行ないました。
0081login:Penguin02/01/20 21:00ID:5whqLm3T
i386 gcc には 最近から
-mpreferred-stack-boundary
ってオプションがあるんですが、gcc-2.95.3 では効かなかったんですよ。
最近のRHは効いているのかも知れません。ちょっと真面目にチェックする
必要ありですね。
0082login:Penguin02/01/22 01:09ID:bDfE+epr
アラインメントなんて知らなかった。
明日ifcで試してみよう。
(((( ;゚Д゚)))ガクガクブルブル
0083login:Penguin02/01/22 20:53ID:wJXZKWBH
>>82
たぶんこれはIFCでは直ってるはず。
というかアセンブラのソース見るわ。
なんだかあおってすまん。
0084  02/01/29 23:03ID:PECJA2Mi
商品版(高い!)と無料DL版との違いはどこにあるの?
0085login:Penguin02/02/03 18:11ID:lkEkFcBp
商品版なんてあったのか。
知らなかった。
0086login:Penguin02/02/04 21:30ID:B2i7yVMD
バグ多くないか?IFCは -tpp7 をつけると
すぐ Internal error が起こる。cast がうまくいかんことないか?
integer*8 で I=iargc() が変な値が返ってくる。
call exitで出られないことはないか(c の wrapperを書きました)。
あーGNUに統合しやがれ!
0087   02/02/08 17:20ID:sam3w5OZ
>>86
CPUは何を使っているの?
0088login:Penguin02/02/08 19:01ID:MfBFWerp
Pentium III で IV の最適化をしてはまってました。
iargcはInteger*4を仮定するのです。
0089   02/02/10 13:05ID:f9cX/woZ
Athlon Thunderbirdで、PentiumIV用のコードを実行させようとすると、
結果がめちゃくちゃ。まああたりまえだけどね。
0090   02/02/13 23:45ID:8/27EbsI
ただ、ただなのは、まだテスト中の製品だったりするからだったから
じゃないのかが不安だ。将来は無料版はなくなるのではないか?
0091login:Penguin02/02/14 08:21ID:qBCCIPAv
g77とか違うコンパイラやマシンで結果が一致するか調べたら
ええんとちゃうか。出来ればGNUに統合されて欲しい。

0092   02/02/16 01:17ID:P37gR3ZU
インテルが商品であるICCとかIFCのソースを公開するかなぁ?
0093名無しさん@Emacs02/02/17 07:24ID:PId1GyBh
コンパイラをGPLにしたとして
それで失う利益よりもPentiumの売上が増える効果のほうが大きければ、
ビジネスとして正しい選択技でしょ。
0094名無しさん@XEmacs02/02/18 01:58ID:iYWvirB6
>>93
Intelに正座して聞かせたい
0095login:Penguin02/02/18 12:42ID:X/HQdXYC
>>93
そのうち g++,g77 が icc, ifc より高速になるYO!
0096login:Penguin02/02/19 10:30ID:ygRZQp1y
ifc では2G以上のファイルをかけないな。
確認した。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:Penguin02/02/19 13:18ID:wHR25Yfq
>>95
正直、それは無理じゃね?
0098login:Penguin02/03/08 09:38ID:0oVxicVH
age
0099login:Penguin02/03/16 20:17ID:jeTKf9Ot
Intel Fortran 6.0 beta が出るらしいな。
いつになるかわからんけど。
0100login:Penguin02/03/17 16:27ID:Y0L5kwur
>>99
4月はじめには正式版出荷。
0101login:Penguin02/04/01 23:00ID:MIY3lWi0
>>100
というわけで4/1にはりこんでみたがまだだった(当然か)。
0102login:Penguin02/04/01 23:56ID:4KjWNtlY
gccってしょぼくねぇ?
最適化とかにはあんまこだわってないのか?
0103名無しさん@お腹いっぱい。02/04/02 00:41ID:BCv0vzPu
こだわっているのは、CPUサポートと言語サポートなんじゃないの?
0104login:Penguin02/04/02 01:21ID:uU1FqcA5
>>102
ふつーに「カナディアンクロスコンパイル」できるのって、gccくらい
でわ?
# XってプラットホームでYで動くZ用クロスコンパイラ作ることね
# <カナディアンクロス
# Linuxで、MinGW/gccコンパイルして、Winのダイアログをコンパイル
# できたときは、ちょっと感動した。(カナディアンじゃないけど)

どこぞで、「おかげでプロセッサに特化した最適化は遅れがち」って
書いてあったぞ。まぁ、だからegcsとかも出てきたり。
でも、「とりあえず、gccは動くだろ」って安心感は、デカイよな。
HP-UXをたまに使うから、つくづく思う。
そーいや、「WindowsでLinuxカーネルコンパイル」とかも理屈上は
できるハズだな。だれか挑戦しない?
0105login:Penguin02/04/02 14:46ID:j7gY85GQ
「カナディアンクロスコンパイル」って
プロレス技みたいだな。なぜカナダ?
0106login:Penguin02/04/02 22:10ID:qqpoU7Yo
GCCはたいていの環境で動いているからGCCよりレベルの低いコンパイラは無く
なる方向になる。とするとGCCが最低レベルのコンパイラになるよな。
# GCCにはコンパイル速度のほうをもっと頑張ってほしい。インライン関数と
# かテンプレートとかたくさん使うと使うとやってられない。
0107名無しさん@お腹いっぱい。02/04/02 23:23ID:BCv0vzPu
>>106
全てのコンパイラを全順序に押し込むわけ?
0108login:Penguin02/04/03 00:51ID:aLlZ/CTX
GNU Autoconf/Automake/Libtoolより
「『カナディアンクロス』の名前は、3つの異なる種類のシステムが
つかわれているような、最も複雑なケースに由来しています。その
ような問題が顕在かしてきた当時、カナダには3つの国民政党があった
ので、このように呼ばれることになりました。」
だそーだ。cygnus用語かな?
0109login:Penguin02/04/03 05:21ID:2DUVTyBB
>>106
ifcで-O2 -tpp7とかやってみ。g77の数倍は時間かかるぞ。
0110login:Penguin02/04/03 23:15ID:FRqVmuPz
uni 板で mozilla を FreeBSD+icc でコンパイルしようとして
失敗しとるヤシがいる。
# http://pc.2ch.net/test/read.cgi/unix/1012057979/l50

Liunx+icc で mozilla をコンパイルした人いる?
0111login:Penguin02/04/04 00:16ID:b5ogLD4j
XFree86をコンパイルしようとしたけど
なぜかプリプロセッサがビミョーにちがうのか、エラーになってしまう
(昔のことだから、メッセージ残ってないしスマソ)

あとオプション変える必要あったりな。
-fPICは-kpicに、-Wl,rpathは知らんのでリンクだけはgccで...
でも前述のエラーとかでできなかった(へたれ)
0112login:Penguin02/04/04 01:45ID:b8zl9fsb
漏れはsnesを…インラインガセンブリ…
0113login:Penguin02/04/19 01:13ID:c5m+sLvD
☆ チン     マチクタビレタ〜
                         マチクタビレタ〜
        ☆ チン  〃  Λ_Λ   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・) <  早くしてよね > 6.0
             \_/⊂ ⊂_ )   \_____________
           / ̄ ̄ ̄ ̄ ̄ ̄ /|
        | ̄ ̄ ̄ ̄ ̄ ̄ ̄|  |

0114login:Penguin02/04/25 13:03ID:s0tjalkG
Intel Fortran Compiler 6.0でてるぜ!
でてるぜ!
check it out!!!
0115 02/04/25 16:54ID:hRAttTY0
なぜか、Non-Commercial Unsupported Software 版
(サポートなしの無料版)は、Fortran も
C++ も、バージョン6.0はダウンロードできないよ。ダウンロード
するリンク自体がいくらさがして発見できない。
(Web でユーザー登録とかをしてみてもだめ)
0116login:Penguin02/04/25 17:20ID:s0tjalkG
いまできてるよ! Form がおかしいときあるよね。
web で登録した後、メールは来た? そこにURLかいてあるよ。
http://developer.intel.com/software/products/compilers/downloads/l_fc_p_6.0.140.htm
0117login:Penguin02/04/26 11:09ID:ybIjNGS+
因に、C++の場合は、
http://developer.intel.com/software/products/compilers/downloads/l_cc_p_6.0.139.htm
だよ。
0118login:Penguin02/04/26 11:52ID:pSUh8qyn
XEONお持ちの方自動並列化のレポートキボンヌ
01196.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:Penguin02/04/26 14:45ID:9G9h10f6
隊長!Debian potatoにはインストールできません
0121login:Penguin02/04/27 13:16ID:l7/+TGKw
>>116,117,119
どうも情報、ありがとうございます。てなわけで
取りに行こうとしたんですが、

https://shale.intel.com/registrationcenter/register.asp

が落ちているのか、つながりませんのでライセンスファイルを
もらえなくて欲求不満です。

それと、みなさん、pgplotってライブラリ、使ってます?
なんかifcだとうまくコンパイルできないんですが。
0122login:Penguin02/05/09 00:58ID:mt4hx9Cg
>>210
超亀レスだが、alienパッケージを入れたあとに普通にinstallスクリプトで
インストールってことが5.0では出来たんだけど、6,0では出来なくなっている?
0123login:Penguin02/05/09 18:28ID:usKCh3+Y
で、結局6.0は5.0と比べてどーなのよ?
速くなっているの?
0124login:Penguin02/05/10 00:38ID:S+u2Lx1o
俺Linuxで数値計算するから勢い込んで導入! って思ったらそんなに速く
ないみたいね、ここ読んだ限りでは。NDA 問題ないから速いかと思ったのに。
そのうち気が向いたらにしよっと。
0125login:Penguin02/05/10 06:52ID:AeDox/td
>>124
君がどんな計算しているのかちょっとわからないけど、
僕の環境ではPentiumIII@1GでAlpha 21264@500MHzとだいたい
同じパフォーマンスだったよ。Pentium4@2Gならもっと高速です。
僕らはpentium4は持ってませんが。また使ってみてください。
数値計算はチューニングが必須です。
0126login:Penguin02/05/10 07:59ID:p++nUXag
>>122
5.0なら問題ないんですけど、6.0の場合はpotatoのRPMのバージョンが
古すぎるのでalienすらできないですね。
d-uに困ってた人居ましたけど、woodyへdist-upgrade必須ではないかと。

>>125
うちの計算もそんな感じです。ほとんどFFTでできてるようなプログラムです。
あと6.0の目玉機能は自動並列化だと思ってたんですが、試す環境にないのが
非常に残念。
0127login:Penguin02/05/10 09:30ID:up11SU+x
intel自身が作っている計算ライブラリーも使えば、高度な
パフォーマンスが得られる場合があるだろう。ダウンロード
してみたらどう?
012812402/05/10 09:32ID:S+u2Lx1o
>>125 サンクス。俺はFPU intensiveな対角化とか分子動力学とか。
今までgccでintelも使ってたけど、alphaには全く太刀打ちできなかった。
けどその話聞くと結構速いみたいね。またintel純正のコンパイラーで
がんばってみるか。
0129login:Penguin02/05/13 11:23ID:9l4vLaBH
>>127
これはMKLのことですか。BlasとLapackを配布していますが、
PentiumIIIではMKLが少し高速です。しかし、Pentium4では
atlasが高速でした。Lapackはよく知りません。
>>128
メモリのバンド幅はあげたほうがいいでしょう。
0130plamoユーザ02/05/13 11:45ID:c5nvN02Z
intelのコンパイラって、rpmでないとインストール出来ないんでしょうか?
slackwareとかplamoのような非rpmなディストリビューションで動かしている
方いらっしゃいますか?

0131login:Penguin02/05/13 12:33ID:YDaaODKg
>>130
SlackやPlamoにrpmコマンドを入れればよかろうが。
ゴルァ!
0132plamoユーザ02/05/13 13:18ID:c5nvN02Z
>>131
そりゃそーなんだけどね。rpm-2.5.1をいれたら「これじゃ旧い」って
怒られるし、rpm-4.0を入れようとしたらライブラリが足らんって言われて
コンパイル通らんし。で、他に方法無いんかなと思って。
地道にやります。失礼しました。
0133login:Penguin02/05/13 13:28ID:9l4vLaBH
僕はFreeBSDな人なんですが、rpm2cpioとかいうのを
使って展開していますね。
0134plamoユーザ02/05/13 18:05ID:c5nvN02Z
>>133
お蔭様で、あっさり動きました。快適です。
有難うございました。
0135 02/05/14 01:52ID:IZxJRGuk
Pentium4のマシンを買うならば、絶対にメモリーの種類が
RDRAMのものを買うべし、買うべし。
0136正直alphaの大メモリ機は高スギ02/05/14 04:21ID:XDFbjSgq
ややスレ違いですが、
xeonマシンだとメモリ8Gとか16G積んでる奴ありますよね。
32bitマシンだと2Gだか4Gだかにメモリの壁があるとどこかで聞いた
覚えがあるのですが、このメモリは単一の計算でめいっぱい使いきれる
のでしょうか?
普通に巨大計算できるのか、並列化しないとできないのかご存知の方
いらっしゃいません?

ちなみにifc6.0用のdebianパッケージがここに置いてありました。
http://www.gfd-dennou.org/arch/cc-env/ifc/
0137login:Penguin02/05/14 05:13ID:XO5C21R+
>>136
Pentium Pro以降のCPUにはPAEというアドレス変換機構がついて
いるので、64GBまでは扱えます。ただし、チップセットの制限に
引きずられますが。あと、変換のオーバヘッドがあるので、
パフォーマンスも悪化します。
Linuxでもこの機能はサポートされてます。

たぶん単一の計算でめいっぱい確保できるでしょう。
0138login:Penguin02/05/14 05:47ID:XDFbjSgq
パフォーマンスの低下がどの程度か気になりますが、大規模計算は
できるのですね。参考になりました。
0139login:Penguin02/05/14 06:10ID:XO5C21R+
しかし、この手の使い方なら実績あるSolaris8とかが良いかと思われ
0140login:Penguin02/05/15 05:38ID:gSF91Ka8
>>137,138
大規模計算をやっている人ならばFortranな人が多いと思います。
sizeof(integer)=8 でないと困るように思いますが、ifcはPentium4
SSE2で64bit integer扱えるはずですが、-tpp7でも
でもそういうコードは吐かなかったです。僕が間違えた可能性は
高いですが。
AMDのx64や、Intel も IA-64 以外にもPentiumの64bit
拡張を考えているようですね。
ではでは。
0141login:Penguin02/05/16 05:17ID:GYM8ysqy
5.0まではAMDのAthlonThunderbirdでFortranコンパイラがちゃんと
作動しましたが、どうやら6.0からは、Athlon上のLinuxでは
コンパイラが動きません。セグメントエラーなどが起きる。
0142login:Penguin02/05/16 06:41ID:5yZwyBjV
マジデスカ?
0143login:Penguin02/05/19 22:26ID:TA85Te6I
>>141
おかしいなと思っていたら、本日マシンはお亡くなりになって
しまいました。M.B.か、CPUがいかれていて、BIOS画面すら起動
しなくなってしまった。
0144login:Penguin02/05/23 01:52ID:MUEwqJ2X
icc 6.0試してみました。Pentium4上でgccとの最も大きな違いはmath関数
にあるようです。expやsin,cosはgccの10倍以上の速度でした。

しかし、ベクトル化はコンパイラの条件が厳しくてほとんどされないし、
されても加速は2倍行かないですね。やっぱり、ベクトル型スパコンとは
違うんだと思いました。


0145 02/05/24 02:38ID:8A5lq9k5
Pentium4用にはどんなコンパイルオプションを使えばもっとも速い
コードがでますかね。
0146login:Penguin02/05/25 19:50ID:7ZkaIBTb
>>144
にわかには信じられん。exp, sin, cos は数値演算プロセッサに渡している
だけだと考えられる。gcc側はへんなライブラリをかませているのか?
0147 02/05/26 02:34ID:7Wq7WMOb
組み込み関数としてインライン展開されたり、MMX命令の類をつかって
いたりするのかもね。パイプライン化に最適なコードを出しているのが
効くのかも。インテルのMATHライブラリーはすごく最適化していると
思う。
0148login:Penguin02/05/26 06:59ID:yJVR8li1
>>147
なるほど!
0149login:Penguin02/05/26 10:25ID:yJVR8li1
>>146
やっぱりよーわからん。多分インライン展開はgccでもやっとると思うが。
あー頭イテ。
0150login:Penguin02/05/26 10:28ID:4fUXbWUZ
>>146
コプロの命令は死ぬ程おそいんだYO
0151名無しさん@お腹いっぱい。02/05/26 11:49ID:ALTTjrt3
つーか、誰か-Sで調べてくれよ。
■ このスレッドは過去ログ倉庫に格納されています