FORTRAN Ⅳ
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2006/11/12(日) 17:13:35FORTRAN77/90/95/2003, HPF等、FORTRAN全般に関する話題を書き込んで下さい。
・FORTRAN関連情報
お約束だが、まずは自分で調べよう
http://www.google.co.jp/
x86で動作するFortranコンパイラ
http://www.nminoru.jp/~nminoru/programming/x86-fortran.html
The Fortran Company
http://www.fortran.com/
Polyhedron Software
http://www.polyhedron.co.uk/
Google Directory - Fortran
http://directory.google.com/Top/Computers/Programming/Languages/Fortran/
・前スレ
FORTRAN III
http://pc8.2ch.net/test/read.cgi/tech/1104724162/
FORTRAN II
http://pc5.2ch.net/test/read.cgi/tech/1068351911/
Fortran
http://pc2.2ch.net/test/read.cgi/tech/1003214738/
0652６５１
2009/10/29(木) 02:15:09POINTERにALLOCATEしたときは連続にメモリーを取るだろうが、
POINTERには、ストライド付きのとびとびメモリーを指示させることもできるので、
最適化には制限が係ることがあるようである。
0653デフォルトの名無しさん
2009/10/29(木) 10:15:13なる～。Fortran77で
i=10000
call hairetu(i)
subroutine hairetu(i)
integer i
real data(i)
みたいな使い方で任意の大きさの配列data()をサブルーチン内で扱えるけど、
これがメモリ上でキチンと並んでいるとは限らない(とんだ部分
の取り扱いはOSがするのか？)からね。
77より後のallocatable属性は、出来るだけ連続して確保してね、の
おなじないというか願掛けと思えばいいのだろうな。
0654デフォルトの名無しさん
2009/10/29(木) 10:49:44moduleが使う変数や関数、サブルーチンを外部から指定したいのですが可能でしょうか？上のコードは間違ってますが雰囲気を掴んでもらえたらいいかなと思い載せました
0655デフォルトの名無しさん
2009/10/29(木) 21:41:04じゃあもうallocate使わない理由はないな
コードも綺麗になるしな
0656デフォルトの名無しさん
2009/11/02(月) 01:28:57まだ2003も碌にコンパイラが無い時点で言っても鬼も大笑いだが。
0657デフォルトの名無しさん
2009/11/02(月) 01:52:59FORTRAN95/2003 Explained 20.2.1 p.331
"A non-pointer array occupies a sequence of contiguous storage sequences 云々"
とあるので、ALLOCATABLE 配列や AUTOMATIC 配列は、連続メモリーが保障されているんじゃないかな。
0658デフォルトの名無しさん
2009/11/02(月) 06:43:35まあ、自動配列も連続したメモリに確保しようとAllocateの時と同じ程度の努力はするよん、ということか。
配列全部が”一つの”連続したメモリ空間に収まるかどうかは、その瞬間のメモリ使用状況によるんだろうな。
大きめの計算機だと、一つのマシンではOSやI/O以外の部分は排他的に使えるから問題は少ないのだろう
といってみるテスト。
0659デフォルトの名無しさん
2009/11/02(月) 11:58:03いや、完全にひとつの連続したメモリー領域なんで内科医？
努力義務ではなくて、必須義務だと思う。
0660デフォルトの名無しさん
2009/11/03(火) 19:38:25もう少し明確に書いて欲しいもんだ（書いてるのかもしれんが）
0661デフォルトの名無しさん
2009/11/04(水) 03:39:24といったところか。努力はするしアテにしてくれてもいいけど、絶対じゃないぞなもし。
0662デフォルトの名無しさん
2009/11/04(水) 04:25:42科学計算以外には向いていないのか？
0663デフォルトの名無しさん
2009/11/04(水) 07:40:31現在では、向いてる向いてない以前に、言語として古い。
0664デフォルトの名無しさん
2009/11/04(水) 12:39:17数式を変形せずになるべくそのままの書き方でコードにできるのが
Fortranのメリットだったはずなのに。
今では使っちゃいけないとされる文関数なんてモロその名残だよね。
0665デフォルトの名無しさん
2009/11/04(水) 12:56:16古いゆえにコンパイラもライブラリも枯れていて、まずバグはない
最適化も一番今の所進んでいる
というわけで信頼性と速度が要求される局面で現在も使われているわけだ
0666デフォルトの名無しさん
2009/11/04(水) 13:02:36FORTRAN以前は演算式もアセンブリで書かなければならなかった、
数式そのものでプログラムを記述出来る事は画期的だったんだよ。
0667デフォルトの名無しさん
2009/11/04(水) 13:47:03張本人でもあるな。
0668デフォルトの名無しさん
2009/11/04(水) 17:57:510669デフォルトの名無しさん
2009/11/04(水) 20:30:220670デフォルトの名無しさん
2009/11/04(水) 20:50:32.eq.は==のほうが見やすくない？
.and.と.or.も早く&&と||が使えるようになって欲しいわ
0671デフォルトの名無しさん
2009/11/05(木) 00:25:280672デフォルトの名無しさん
2009/11/05(木) 01:44:31賛成。
等号不等号は数学記号のほうがいいが、.AND. .OR. はこっちのほうがいい。
&&､||は見てくれからしてイマイチ。
歴史的にもEBCDICに無い記号だから、FORTRANに入ろうはずも無かった。
APL端末使えばいいのかも知れんがｗ
0673デフォルトの名無しさん
2009/11/05(木) 05:16:5510進数浮動小数点の小数点、理論演算子の飾り、structureの区切り
で使われるからメンドイw。
目の慣れだろうな。自分は .AND. .OR. の方がみやすいけど。
スペース無しだとみにくいけど。
0674デフォルトの名無しさん
2009/11/05(木) 13:53:38これはもう好みの問題だろうなぁ。
自分は記号のほうが、英数字に対して違いが際立つんで好きだな。
あと、文字数が少ないのもいい。.AND.は5文字もあるし。
>>673
＞10進数浮動小数点の小数点、理論演算子の飾り
揚げ足じゃないが、これはコンマじゃなくてピリオドじゃ
0675デフォルトの名無しさん
2009/11/05(木) 14:16:56C言語は特殊事情があるんだよ
史上最も記号が多い言語はAPLで、未だにこの言語を超えるものは
出ていないが、第二位にC言語となっている(今はC++)
C言語はとにかく予約語をできるだけ減らしたくて、多くのワードを記号に
したと言われている
そのためC言語の予約語はわずか32個しかない
C++はCより記号が多いにも関わらず予約語はかえって増えた
C++0xでは更に増える
0676デフォルトの名無しさん
2009/11/05(木) 17:40:23記号も予約語も増えるよなぁ
FortlessはUnicodeで演算子を定義できるらしいから、もしかしたら使える記号の
数ではAPLを越えるかもw
0677デフォルトの名無しさん
2009/11/05(木) 17:41:110678デフォルトの名無しさん
2009/11/05(木) 19:23:08Sun・・・(´；ω；｀)ﾌﾞﾜｯ
0679デフォルトの名無しさん
2009/11/05(木) 19:28:56ttp://projectfortress.sun.com/Projects/Community/blog
0680デフォルトの名無しさん
2009/11/06(金) 02:10:17そういわれるとFortranは0-9,a-Z以外に使う文字は少ないね。
{}[]@^_%~`;<>?|\ は使わないでも済むね。[]%\ は使う状況はあるけど代替があるし。
固定書式で継続行に使うとかしないと使わない文字が多い。
＄は微妙。規格外だけどたまに使う。＃はプリプロセスしてれば使うなけど標準ではないな。
0681デフォルトの名無しさん
2009/11/06(金) 08:04:000682デフォルトの名無しさん
2009/11/06(金) 11:19:25ASCIIコードを使ってるのは、ミニコンとかWSとかパソコンとかしょぼいマシンだけだったんだよ。
F90の規格に、やたらと固有文字コードとASCIIコード変換とかあるのはそのため。
小文字が端末から使えないことも多かったし。
数値フォーマットもバラバラだったから、数値の基数や有効ビット数を尋ねる関数もそろってる。
0683デフォルトの名無しさん
2009/11/06(金) 12:09:53System/360にもASCIIとの切り替えスイッチは付いてたんだけどなw
0684デフォルトの名無しさん
2009/11/06(金) 12:19:22そうなのかｗｗｗ
0685デフォルトの名無しさん
2009/11/07(土) 02:57:410-9 A-Z .,()=+-*/'
だけか。見落としなければ46文字。Spaceが必須でないところがなんともイカす。
使われる文字数が少ないのはパンチカード時代があるからだろうな。
Viで編集しやすいわけだw
0686デフォルトの名無しさん
2009/11/07(土) 08:52:27scanf()なんてあれはパンチカード時代の名残
とにかくタイプ量を減らしたくて多くの予約語を演算子に変えた
0687デフォルトの名無しさん
2009/11/07(土) 10:01:38C言語の発祥は主にミニコン文化圏で、パンチカードじゃなく、紙テープとテレタイプが主流。
記号だってEBCDICにないものを多用するし（そのせいでトライグラフなんてものも
できたりしたがw）
0688デフォルトの名無しさん
2009/11/09(月) 03:54:200689デフォルトの名無しさん
2009/11/09(月) 09:36:45機能の代替がない、という点では：の添字範囲指定もかな、ってあれ
１以外から範囲指定可なのはF77でも出来たっけ？
0690デフォルトの名無しさん
2009/11/09(月) 09:37:570691デフォルトの名無しさん
2009/11/09(月) 23:59:27７７では配列の宣言のところだけだったか、文字列では部分文字列の指定に使えた。
あとフォーマットでもコロンが使えたはず。
0692デフォルトの名無しさん
2009/11/11(水) 02:45:21mojiretu = 'smtwtfs'
write(*,*) mojiretu
mojiretu(2:6) = 'sssss'
write(*,*) mojiretu
みたいな使い方の事だね。規格が30年くらい前だけど、その後のベクトル表現の匂いがする。
そういう文字列取扱いの需要があったからだろうけど、先をいってたんだな・・・たぶん。
フォーマット中の例が思いつかなかった。
0693デフォルトの名無しさん
2009/11/30(月) 16:44:28もうしばらくは様子見だけど
そういえば、CUDAが徐々にFortranに対応してきてるようだけど、使ってる人いる？
0694デフォルトの名無しさん
2009/12/01(火) 00:04:39PGI が CUDA 対応 Fortran2003 を出荷し始めたみたいだけど、誰か使ってないのかな？
GPGPU も昔のアレイプロセッサとよく似ているから、すぐ廃れて終わるとか言う話も聞いて
なんなんだかなーｗ
0695デフォルトの名無しさん
2009/12/01(火) 21:46:47まぁ、うまくいけばIntelの二番煎じなポジションから脱却できるしな
0696デフォルトの名無しさん
2009/12/14(月) 01:04:11>>2の
http://www.salfordsoftware.co.uk/
のどこからダウンロードするのかみつからないんですけど教えてくれますか？お願いします
0697696
2009/12/14(月) 01:05:55すみません
0698デフォルトの名無しさん
2009/12/17(木) 14:58:51Intel secretly redesigned key software, known as a compiler,
in a way that deliberately stunted the performance of competitors’CPU chips.
だってさ
0699デフォルトの名無しさん
2009/12/18(金) 00:24:240700デフォルトの名無しさん
2009/12/18(金) 22:51:01今後Windows XPの提供が終了すると新しいPCに使用出来なくなるので
新たなコンパイラーと数値計算ライブラリを探しています。
どなたかお勧めのメーカを教えてください。
条件は、Windows Vista & 7上で動作するコンパイラーとライブラリで
リーズナブルなもの。
パソコンは私１人で70台くらい使っています。
(Fujitsu製のライセンスは使用する人数にかかり、
PCの台数には関係なかったので重宝していたのですが。)
よろしくお願いします。
0701デフォルトの名無しさん
2009/12/18(金) 23:31:050702デフォルトの名無しさん
2009/12/19(土) 15:46:30HPCが盛んになりつつある時代にこんなことやってたら
某機関に目を付けられて即死なんじゃｗ
0703デフォルトの名無しさん
2009/12/20(日) 05:34:390704デフォルトの名無しさん
2009/12/21(月) 18:27:540705デフォルトの名無しさん
2009/12/22(火) 10:23:48MPICHのインストール時に set F90=~/Microsoft Visual Studio/DF98/Bin/f90
としてみたのですが、認識しませんでした。
0706デフォルトの名無しさん
2009/12/26(土) 10:50:240707デフォルトの名無しさん
2010/03/28(日) 18:31:28皆さんのお勧めはどちらですか？
実行速度とか，GPGPUとか，並列化とか，Visual Studio 2008 に統合してコーディングしているときの
使い勝手の良さとか，コンパイラの厳密さとか（← 変数宣言部で配列を a(3) と宣言しているのに，
実行部で a(4) = 1 と書いたとき，IVF のコンパイラはエラーを出してくれたけど，PVF のほうは
エラーなしでコンパイルが成功してしまった），その他色々な面でどうでしょう。
0708デフォルトの名無しさん
2010/03/28(日) 21:32:36つか、Windows 環境で Fortran が信用できていない
# Intel は, まぁ, ましな部類だと思う
0709デフォルトの名無しさん
2010/03/29(月) 00:21:06>実行部で a(4) = 1 と書いたとき，IVF のコンパイラはエラーを出してくれたけど，PVF のほうは
>エラーなしでコンパイルが成功してしまった），その他色々な面でどうでしょう。
６６時代は整合配列が未整備だったので、サブルーチンとかの先では配列サイズを適当に固定して
はみ出して使うことがよくあった。歴史的事情から一概にエラーにするわけにもいかんのよ。
コンパイラのオプションとかで厳格な判断ができるはずだと思うから、調べてみてちょ。
IntelFortranにも90,95,2003毎の規格違反警告オプションが有る。
そういえば最近のPGI Fortranは米国大学研究機関に所属であれば、Win用が無償で使えたような？
キャンペーンはもう終わったかもしれないが。
0710デフォルトの名無しさん
2010/03/29(月) 03:32:410711デフォルトの名無しさん
2010/03/29(月) 12:08:17できない。
CUDAのAPIをCALLするという意味でならできなくも無い。
Fortranのラッパーを書くオープンソースなプロジェクトが動いていたはず。
GPU側で実行する部分は無論Cで用意するのだとおもうが。
0713デフォルトの名無しさん
2010/03/30(火) 03:50:29インテルのは添字範囲チェックが甘いよね。柔軟ともいえるけど・・・。
コンパイル時の警告のよさ？では gfortran -Wall あたりがいちばんかなぁ
以前はDEC系でいいのがあったんだけどね。さすがに今では。
0714デフォルトの名無しさん
2010/03/31(水) 06:17:02real a(10)
call hoge(a)
subroutine hoge(a)
real a(2)
a(10) = 1.0
というのがあって、スルーする大人がインテル。実際メイン階層では配列a(10)の内容に問題ないわけだ。
文句いうのがGfortranやFujitsuやPGIやIBMやNEC
0715デフォルトの名無しさん
2010/03/31(水) 16:56:36そのsubroutineはモジュールじゃない、普通の外部サブルーチンという前提だよね
a(11)=1.0をやるとエラーになる？
0716デフォルトの名無しさん
2010/04/01(木) 02:37:19そ、ただのSubroutine.
Module は値の追跡が面倒臭いし、コンパイル時に順番が関係するし、
Commonと同じような奇妙な振舞をする事もあるので自分では使わない。なれると便利らしいけどね。
a(11)=1.0
そのものにたいしては、コンパイル・実行時ともに文句をいわなかった。(以下ぜんぶIntel.他のはしらない)。
でも実行時にはcall hoge()のあとに a 以外の変数が壊れたりw、 hoge() 内で Invalid なんたららが
でたり・・コンパイルオプションでも変わる。何事もなかったかのように実行終了することもあるw
Intel Fortran は速度的には良いコンパイラだとおもうけど、
開発中に使うには危険な香りがするのでふだんはgfortran。
Intel のでも Visual がつく方はまだいいのかなあ？ HPはもうDEC系譜のFortranは終了だよね。
0717デフォルトの名無しさん
2010/04/01(木) 11:50:28MODULEつかえよｗ
型チェックとか便利だろ。
場合によっては最適化度もあがるはず。
まぁカスケード型のリコンパイルの嵐が起きるのがウザイのはわかるが、
あれもF2008でSUBMODULEが導入されてなんとかなる。
0718デフォルトの名無しさん
2010/04/01(木) 13:34:16というかググってもあんま情報ない気が
どこで勉強すればいいの？
0719デフォルトの名無しさん
2010/04/01(木) 14:28:48他のはコンパイルエラーでそれ以上進めなかったから。
>>717
ある程度なれてマイModuleつくるともう戻れないくらいイイらしいね。
麻薬のようにもう抜けれなくなる、わけではないのだろうけどｗ
でも不慣れなときにコンパイルするだけにかなりもがいた
つらい経験をしてしまったので敬遠中。でもそのうち使うと思うよ！
>>718
F2008って規格の部分だけでも読めないのかな？
ベンダが対応するとかしないと商業レベルの本は出ないと思うので
(出ても日本語のがでるのかはあやしいが)せめて予習ｗくらいはしておきたい。
0720デフォルトの名無しさん
2010/04/01(木) 16:57:44初心者だけど動的割付配列のためにモジュール使ってます
やっぱりコンパイルエラーやらは多いですね
0721デフォルトの名無しさん
2010/04/02(金) 01:32:14それはたぶんF２００３。
まだ完全対応コンパイラがCRAYしか出してない。
勉強の手始めは、PDF直リンだが
ttp://www.itscj.ipsj.or.jp/forum/forum2008SC22fortran/Fortran20032008.pdf
The New Features of Fortran 2003
ttp://www.ipc.bas.bg/PPages/Bogi/newFortran2003.pdf
F2003は英文なら、なんぼか教科書もではじめている。しかし2003部分は１章程度だったりでいまいち。
F2008は
The new features of Fortran 2008
ftp://ftp.nag.co.uk/sc22wg5/N1701-N1750/N1729.pdf
こっちはまだ規格の最終ドラフトができた段階で、正式規格ではない。最終ドラフトはただで見れる。
ここで↓
ISO規格の議論をしている本家
ttp://www.nag.co.uk/SC22WG5/
0722デフォルトの名無しさん
2010/04/02(金) 08:05:250723デフォルトの名無しさん
2010/04/02(金) 09:13:000724デフォルトの名無しさん
2010/04/02(金) 10:58:310725デフォルトの名無しさん
2010/04/02(金) 12:15:070726デフォルトの名無しさん
2010/04/06(火) 06:01:132次元配列の一部分だけをサブルーチンに送った場合、その部分的な要素だけを
繋げた別の配列が一時的に作られて処理をされるのでしょうか？
例えば、主プログラム冒頭で
integer :: x(10 , 20)
とした場合、メモリ上に10 * 20 の配列が出来ますよね？
これを call hoge( x(3:8 , 12:19) , ... ) とすると、
6 * 8 の一時的な x’ が別途メモリ上に作られたうえで
それがサブルーチンへ送られるのでしょうか？
膨大な配列を扱うので、なるべく効率的なプログラムを書きたいのです．
勉強し始めの者なので、トンチンカンなことを言っていたら恐縮です...
0727デフォルトの名無しさん
2010/04/06(火) 10:22:37そういう連続していないのはcopy in - copy outで中間のテンポラリ配列が暗黙に作られる。
一次元に還元したときに連続している場合は、コピーを作るかどうかは場合によると思う。
0728デフォルトの名無しさん
2010/04/06(火) 17:30:33いずれにしても、call hoge( x(3:8 , 12:19) , ... ) だと「一次元に還元したときに連続」していないから、コピーは避けられないだろうな
0729デフォルトの名無しさん
2010/04/06(火) 17:55:200730デフォルトの名無しさん
2010/04/06(火) 18:10:43紛らわしいぞｗ>>729
0731726
2010/04/07(水) 07:28:05なるほど。どうもありがとうございます。
余計なメモリを消費させないためには、
call hoge( x(3:8 , 12:19) , ... ) は避け、
call hoge2( x, 3, 8, 12, 19, ...) などとして、サブルーチンへは x のまま渡して
実際に操作したい配列要素番号も別に指定するといった方法が良いって理解でよいでしょうか
もう一点質問があるのですが、
call hoge2( x, ... ) と call hoge2( x(:), ... ) は全く同じものでしょうか？
コンパイラーによりけりですか？
0732デフォルトの名無しさん
2010/04/07(水) 19:52:50あくまで自分の理解だけど
＞理解でよいでしょうか
yes
＞全く同じものでしょうか？
yes
0733デフォルトの名無しさん
2010/04/08(木) 00:15:00天然バカｗｗｗｗ
0734733
2010/04/08(木) 00:16:10★「政治家がばかでは国もたぬ」＝公務員研修の訓示で鳩山首相
・鳩山由紀夫首相は７日の国家公務員合同初任研修開講式で訓示し、入省したばかりの
新人を鼓舞したが、その中で「政治家がばか者の集団では（国は）もたない」などと
脱線気味に発言する場面があった。
首相は弟である鳩山邦夫元総務相が政治家を志した際、大蔵事務次官を経て
政界入りした父威一郎元外相が「政治家なんてものは物ごいをする情けないばか者だ」と
反対した話を紹介。「父親は役人だったことに誇りを感じていた」と語る一方で、
「トップの首相が大ばか者であれば、そんな国がもつわけがない」と繰り返した。
首相としては、政治主導への決意を示しつつ鳩山内閣の優秀さを強調したかったようだが、
指導力不足や自らの発言をめぐる迷走が指摘されているだけに、新人公務員も複雑な
表情だった。
http://www.jiji.com/jc/c?g=pol_30&k=2010040700743
0735デフォルトの名無しさん
2010/04/08(木) 08:05:380736デフォルトの名無しさん
2010/04/08(木) 11:25:29鳩山さんこそスレタイ見てください。
0737デフォルトの名無しさん
2010/04/08(木) 17:04:56バカ
0738デフォルトの名無しさん
2010/04/09(金) 23:07:010739デフォルトの名無しさん
2010/04/17(土) 01:15:02PRINT *, LOOPY
END
0740デフォルトの名無しさん
2010/06/19(土) 00:14:190741デフォルトの名無しさん
2010/07/05(月) 17:00:13GNU, Intel, PGIなどのメジャー所でいいので、ざっくり予想してくれませんか？
0742デフォルトの名無しさん
2010/07/06(火) 00:14:50F2003すらまだだというのにF2008を予想せよとはきつい。
そもそもまだISOのFinalDraftの段階で、正式な規格にすらなっていない。
ジェッターマルスの時代＊１を超えて、ケムール人＊２の時代くらいじゃないか？
＊１ ttp://www.youtube.com/watch?v=Xpxb55WHx2s
＊２ ttp://www.youtube.com/watch?v=S6q-lbd6WVM
0743デフォルトの名無しさん
2010/07/06(火) 15:10:37Intel Fortranを調べてみましたが、確かに2003は完全対応してないですね。
コンパイラの対応ってスピード的にもこんなもんなんですかね？
あと、ジェッターマルスっていうのは鉄腕アトムのリメイクなんですね。
40後半とお見受けしました。
0744デフォルトの名無しさん
2010/07/08(木) 01:29:34Intel掲示板のSteve Lionelのカキコでは、IVFの2003完全対応はv12.0になってからということだった気がします。
（ソースカキコが見つからないｗ） 今のところ新機能のうちでは、parametric type が全く手付かずなので、
今年中は完全対応は無理かな？
ただ規格への対応スピードはこんなもんじゃないですかね。C99なんかも１０年くらいかかっていますし。
ACM SIGPLAN Fortran Forumに、コンパイラのF2003対応度の記事が毎号載っていますので、御参考までに。
ttp://portal.acm.org/browse_dl.cfm?coll=&dl=ACM&idx=J286&linked=1&part=newsletter
有料ですが・・・
ジェッターマルスは、著作権の関係で手塚治虫自身が作ったアトムのパチモンで、リメイクとはちと違うんです。
パチモンらしく、なんとも冴えない・・・
0745デフォルトの名無しさん
2010/07/08(木) 13:03:50IntelFortranには今度こそIntellisenseに対応してもらいたいものだ
0746デフォルトの名無しさん
2010/07/08(木) 13:13:3364*64*128元の連立方程式Ax=bを解くためにmklを使っています。
係数行列の因子分解までは並列化して計算されるのですが、
求解の部分ではCPU使用率が100%になって並列化されません。
解を求めるところをコメントアウトするとCPU使用率が800%になるので
求解の部分で並列化されていないのは確かだと思います。
pardiso、dssを試しましたが、両方とも同じでした。
抽象的な質問で申し訳ないですが、どうして上のようなことが起きるのでしょうか？
そもそも求解の部分は並列化されていないのでしょうか
mklのバージョンは
Math Kernel Library 10.1 for Mac OS* X
ifortのバージョンは
ifort (IFORT) 11.0 20081105
計算機は
Mac OS X 10.4.11
Quad-Core Intel Xeon 3.0GHz x2
コンパイルオプションは
-ipo -O2 -unroll2 -openmp -openmp-report2 -lmkl_solver_lp64 -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread
pardisoでは
export OMP_NUM_THREADS=8 とした上で、iparm(1)=0,iparm(3)=8としています。
よろしくお願いします。
0747デフォルトの名無しさん
2010/07/08(木) 14:24:28よりほんのり大きい数字の配列にして・・・・とか、かな？あてずっぽ。
MKL って最近使ってないけど同じく OpenMP で扱う予定なので・・・
偉い人の出現を一緒に待とうねｗ
0748デフォルトの名無しさん
2010/07/08(木) 14:26:07-unroll2
を
-unroll0 (アンローリング Off)
-unroll (適当なデフォ値、たぶん８)
にしても同じかな？
0749デフォルトの名無しさん
2010/07/08(木) 14:29:52Inter-procedural Optimizer を切るか、
もし743さんの作ったソースが一個だけなら、
-ip にして自作ソース内だけにInline 最適化を控える・・とか。
・・・でも100％きっちりで止まってるのなら、あまり関係なさそうだｗ
0750デフォルトの名無しさん
2010/07/08(木) 15:43:18普通は行列のタイプ（粗密とか）で選ぶと思うけど
0751デフォルトの名無しさん
2010/07/08(木) 19:29:00>>750
対象としている行列は疎行列です。
使ったのはmklの中にある
pardiso(並列化対応直接法スパース ・ ソルバー)と
dss(直接法スパース ソルバー)です。
>>747-750
すべて試してみましたが解決はできませんでした。。。
あと、ソースは複数あります。
■ このスレッドは過去ログ倉庫に格納されています