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 ページからダウンロードしてくるファイルが違うだけです。)
ダウンロードする際に入力したメールアドレスにインストール時に必要となる
ライセンスキー情報が送られてきます。
005350
02/01/19 15:51ID:umOrHyJq私も
＞おかげでf90がただで手に入るようになったわけで
と言いたかったのですが…。
取り敢えず今まで通りvf90使っておきますか。
選択肢が増えたわけだからそれぞれの癖さえ掴めばいいのですかね。
0054login:Penguin
02/01/19 17:03ID:/efnsvv4基本的に4bytesのアラインだからやねんな。
mallocで取られるcとはちがい、fortranの場合は
大きな配列をスタティックにとってというはなしになるから
結構致命的になると思う。sbrkなんか使うなよなぁ。
訳解らん。
>>53
RH7.1 のgccってそんなに高速なんだ。知らなかった。
HPCのページを見てると不当にg77の評価が低くて、
かなりむかついた。それ以来あそこのデータは信用したくない。
というか、チューニングなんてマニアがごりごりやったやつと
何も考えずに組んだやつだったらそりゃちがうだろう。
どうせチップとか作ってるわけじゃないのにえらそうに。
なんだか嫌なやつらだ。
ま、ベンチとってくれてありがとう、とは思うけど。
0055login:Penguin
02/01/19 17:06ID:/efnsvv4あ、僕があおられているだけか。
ところでRHのBLASはコンパイルはそのままで
手は加わってないんだよね?なぜATLASより遅いんだろう?
あんまり知らないですが。知ってたら教えてください。
やっぱPenIVなんやろうな。
0056login:Penguin
02/01/19 17:21ID:umOrHyJqVine-2.0に(おまけで)付いてた富士通のフォートランはそのころのg77より
ずっと速かった覚えがあるけど、>>51 ではg77が速いって言ってるから、
多分g77の性能が上がったんだと思う。
あとそのころでもgccと富士通のCコンパイラとは互角の性能出てた。
もちろん計算の種類にもよるだろけど。
0057login:Penguin
02/01/19 20:42ID:T0M+fgYBあげると急に速くなること
あるね。
p4のｍｋｌはSSE2に対応してる。
これとほぼ同じベンチを
red hat7.1についてくるblasが
たたき出す。自分でコンパイルした
blasはへたれ。>>55 さんは
自分でコンパイルしたのですか。
それとred hatは7.1っすか。
ppc2002でのカキコは疲れるな。
0058login:Penguin
02/01/19 22:16ID:CcBGA9H/分かるのでしょうか? 僕は FreeBSD or make を
そのままするんでよくわからないんです。
フラグは? レファレンスインプリメンテーションのコンパイル?
ううううーむ。ちょっと信じられない。
分かる範囲でよろしければ教えていただくとうれしいです。
0059login:Penguin
02/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:Penguin
02/01/19 22:41ID:CcBGA9H//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:Penguin
02/01/19 22:51ID:1EgeSYjkblasに秘密がある気がするんだが。
0062login:Penguin
02/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:Penguin
02/01/19 23:11ID:umOrHyJq>>61 はただ lapack が blas を呼んでいる程度の意味だと思うが。
0064login:Penguin
02/01/19 23:14ID:X8kahLTF0065login:Penguin
02/01/19 23:19ID:umOrHyJqちなみに >>30 >>32 は漏れ。ちょっと責任感じてみたり…。
最初の目的は有名どころのコードをmakeしてみてicc ifc の癖掴もうと思ってたんだが…
0066login:Penguin
02/01/19 23:26ID:CcBGA9H/すまぬ。Intel Compiler スレだ。
しかしながら、icc, ifc は最適化に優れていると聞くが
どの程度なのかはコードの実行スピードを見ない限り分からないではないか。
とりあえず、BLAS, LAPACK は、数値計算ライブラリとして重要な
位置を占めておる。それらの最適化はそれこそ我々の飯の種なのだ。
ということで、ちとマニアックな話+ifc に関係ない話をするかも
しれないが、やはりifcの性能は気になっておるんだ。
まぁ結論はなかなか出ないと思うがきいてやっておくれ。
0067login:Penguin
02/01/19 23:33ID:CcBGA9H/+ 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=61
02/01/19 23:51ID:pz4lxlErでは、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。
006968
02/01/20 00:01ID:tTEZ7bJ8そうですか。私のblas、lapackのmakeの
仕方が悪い（-march=i386 -mcpu=i686というオプションを
つけてないと思います）のかもしれませんね。
lapackを自分でmakeしたときnetlibの
汎用のを使いましたが、もっとintel系のlinuxに
適したものなのかな？
とりあえず、g77,pgfortran,ifcでやってみて一番
速いのを流すという方針がいいんですかね。
007065
02/01/20 00:16ID:248hne5/そですね。各コンパイラでコンパイルオプション適当に振って、
一番できのいいのを探して、それを使うのが結果として時間の
節約かも知れませんね。
ところで少し気になることは、ifcで、blasやlapackのように相当作り込まれ
たコードをコンパイルしてもそれほど効果無いようなのですが、自前の
ヘボコードなどをコンパイルすると2倍程高速化しているような気がします。
僕の場合はまず自分の腕を上げることのほうが先のようです…トホホ
0071login:Penguin
02/01/20 00:25ID:5whqLm3T>>70
研究者の方ですか? そうやったら別にいいのでは。可読性のほうが
重要ですよ。二倍程度の高速化やったらコンパイラに任せた
ほうがいいかも知れませんよ。頭の体操にはいいかもしれませんが。
>>69
いろいろ流し直すのって面倒じゃないですか。だから噂程度で
ifc 万歳とか思ってたんですが、g77もがんばるわけですねぇ。
ううーむ。
007269
02/01/20 08:43ID:K/B4TT8Aシミュレーションなんで、
結果がでてくる時間がオプション、
コンパイラで大分違うんです。
前にalpha 21264 で、手製の
lapack-blasをcxmlに変えたら
劇的に加速したこともあり、
以来、色々と試すことにしてます。
0073login:Penguin
02/01/20 11:39ID:5whqLm3Tアラインメントは?
2ヵ月と4ヵ月では全然違いますよね。
007469
02/01/20 13:32ID:0V/4SmC44月と２月で違うのって、
nelibのlapackですか。
もっと古いかも。そんなに
違うと思ってなかったんで、
無理に最新にしてなかった。
機能までアラインメントも気にして
なかったし。まだまだ、
やること、ありそうです。
0075login:Penguin
02/01/20 15:33ID:5whqLm3Tすんません。数ヵ月単位のジョブと言うと2ヵ月が4
ヵ月というのが全然違うということです。
アラインメントは重要です。PentiumIVならもっと
違うかも知れません。Intel の compiler ならそういうのを
しれっとやりそうですが。
007674
02/01/20 15:45ID:Zx6TOajkちゃんと2ヶ月、4ヶ月とかいてありましたね。
PDAから見てたもので、読み方が荒かったです。
もうしわけありません。
昨日、この板でアラインメンとを知って、
びっくりしてるところです。そういえば
思い当たるふしもあったので。それと、
今までのベンチマークは
time ./a_g77.out
time ./a_pgf77.out
time ./a_ifc_lapack.out
time ./a_cfla_O5.out
というようにコンパイラ、コンパイルオプション
ごとに、実行ファイル名を変えていたのですが、
これはまずいですね。月曜日から、いろいろと
することがありそうです。
007776
02/01/20 16:12ID:Zx6TOajkg77,ifcはファイル名を変えても実行速度が
あまり変わりませんでしたが、pgfortran
は16%ほど、速いファイル名とそうでない
ファイル名と分類できてしまいました。
g77はf90に対応してないので、f90は
仕方なくpgf90でやってましたが、
これからはifc,pgf90の両方で試し、
かつ、ファイル名をいろいろと変えて
走らせることにします。
幸い、自分の今の計算は長い計算を
一回というのでなく、反復計算が
多いので、このファイル名を変えるというのが
実現可能です。
0078login:Penguin
02/01/20 16:23ID:5whqLm3Tなんだか混乱させるようで悪いですけど。問題は
ファイル名だけではないのです。スタックのアラインメントの
問題だから、シェルの種類やもしかしたらコンディションで
変化するかも知れないのです。詳しくは僕も分かりませんが、
シェルが子プロセスを走らせるときのアラインメントが違えば
ファイル名だけで対処することはできません。
LinuxとFreeBSDだと微妙にアラインメントのブレは違うのですが、
これまた大きな問題です。Cの場合は適当にスタックを
変化させるように最初にいれておけば問題は無いですが、
Fortranの場合はどうしたらいいもんか?
いろいろがんばってみましたが、FreeBSDはカーネルパッチ
があって、なんとかコミットされたらと思いましたが
コミットされる前にページ毎消えちゃいました。
はぁー。
0079login:Penguin
02/01/20 16:31ID:5whqLm3Tとりあえずこのスレの僕の書き込みでURL示してるのがあるので
ちょっと見てみてください。
0080login:Penguin
02/01/20 17:31ID:C3Sbw68k実行するごとに微妙（0.2 秒）
くらい、実行時間が変わるのは
環境のためでしたか。
一つ分からないのですが、
ファイル名を１文字、２文字、、、、と
８通り作ると、pgfortでは実行
時間が１５秒と１８秒のものに
きれいに分かれるんです。
もちろん、コンマ１、２秒の
誤差はありますが。
g77, ifcでは１０秒なので、
pgfortの最適化があまいのは
明らかなのですが。ちなみに
実行時間の測定は２回ずつ
行ないました。
0081login:Penguin
02/01/20 21:00ID:5whqLm3T-mpreferred-stack-boundary
ってオプションがあるんですが、gcc-2.95.3 では効かなかったんですよ。
最近のRHは効いているのかも知れません。ちょっと真面目にチェックする
必要ありですね。
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名無しさん＠Ｅｍａｃｓ
02/02/17 07:24ID:PId1GyBhそれで失う利益よりもPentiumの売上が増える効果のほうが大きければ、
ビジネスとして正しい選択技でしょ。
0094名無しさん＠ＸＥｍａｃｓ
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ってのを使えってさ。
■ このスレッドは過去ログ倉庫に格納されています