Path: coconuts.jaist!wnoc-tyo-news!etlnews.etl.go.jp!news.trc!nf2.iij.ad.jp!nr0.iij.ad.jp!news.iij.ad.jp!rim.or.jp!Q.T.Honey!quest-news!news.t.u-tokyo.ac.jp!news.nc.u-tokyo.ac.jp!makino From: makino@grape.c.u-tokyo.ac.jp (Jun Makino) Newsgroups: fj.comp.lang.fortran Subject: Re: 構造体は使うべきでないと思 Date: 12 May 1998 01:04:36 GMT Organization: College of Arts and Sciences, Univ. of Tokyo Lines: 104 Message-ID: <6j8774$da0@news.nc.u-tokyo.ac.jp> References: <6j773t$qi3@news.nc.u-tokyo.ac.jp> NNTP-Posting-Host: provence.c.u-tokyo.ac.jp X-Newsreader: mnews [version 1.19PL2] 1996-01/26(Fri) Xref: coconuts.jaist fj.comp.lang.fortran:26 の記事において onizuka@mpapia.trc.rwcp.or.jpさんは書きました。 >> FORTRAN ユーザって、こういうライブラリは使う人であってあんまり作る人じゃ >> あないですからね。行列があって、それを与えて逆行列にしてくれたり、固有 >> 値解いてくれたりすれば、それで良いのであって。その中がどうでもよい。イ >> ンタフェースとして、引数の順番とかがわかっていれば、なにもデータ抽象化 >> でパッケージやらんでも良いのです。それが操作主義でしょうね。 配列を与えれば逆行列が返ってくる、計算の方法は知らんというのも立 派な「データ抽象化」だと思いますが、、、そういうのを操作主義って いうんですか？ >> >というわけで、これはそんなことはないと思います。少なくともプログラムが >> >3倍（以上）長くなって、間違いの余地も増えるわけですし（鬼塚さんはもち >> >ろん承知のうえでかいていらっしゃるのだと思いますが）。ちょっと古いです >> >が Connection Machine 上の C* とかは、数値計算にはわかりやすいものだっ >> >たと思います。 >> >> この話は、実際分子動力学をやっている人と話したときに感じたことです。そ >> の人にとっては、どうしても、C++ みたいなまとめ方が理解できないというわ >> けです。非常にわかりにくいらしい。 えーと、斉藤さんですか？だとすれば、失礼ですが、鬼塚さんの説明が よほどまずかったんじゃないかと思います。 >> データの転送量を計算するのが面倒ですよね。構造体のサイズを計算するとこ >> ろとかね。REAL*4 とか REAL*8 が N 個だったら簡単ですけれど、オブジェク >> トが、三次元ベクトルと質量と、、、、を持っているという場合、そのサイズ >> を計算して、その結果で送る、というところを頭で計算するか、Cだったら >> sizeof 使うか、まあ、どっちにしても一回考えないといけない。面倒です。 例えばの話、 real * 8 x(N), ........ ... call send(x(k),nsend) call send(y(k),nsend) call send(z(k),nsend) call send(vx(k),nsend) call send(vy(k),nsend) call send(vz(k),nsend) call send(ax(k),nsend) call send(ay(k),nsend) call send(az(k),nsend) call send(ax(k),nsend) call send(ay(k),nsend) call send(az(k),nsend) call send(jx(k),nsend) call send(jy(k),nsend) call send(jz(k),nsend) call send(t(k),nsend) call send(dt(k),nsend) call send(m(k),nsend) と書く方が struct particle{ double x[3]; double v[3]; double a[3]; double j[3]; double t; double dt; double m; }PARTICLE; PARTICLE p[N]; ... send(p[k], sizeof(PARTICLE)*nsend); と書くより面倒ではないとはなかなか思えないのですが、、、 >> いやあ、現在大規模並列処理の主流は、ほとんど FORTRAN + MPI です。C++ >> なんてほとんど使わない。C ですら使わないです。 そりゃあ、ベクトル化も並列化もしてくれなきゃ使いようがないですか ら。 >> >これはその通りですね。で、結局ベクトルの機械とか、ベクタ・パラレルの機 >> >械では Fortran で書かないとまともなベクトル化／並列化をしてくれないし、 >> >SMP 上の KAP なんかでも事情はあまり変わらないですね。 >> >> もうやれるところはやってしまったらしいから、これ以上は重箱のすみをつっ >> つく問題らしいですしね。 そうですか？商品レベルでは、 Fortran コンパイラならやることを C のはやりませんよ。 >> いや、私の印象だと９０％以上が FORTRAN + MPI です。だから、並列コンピュー >> タの場合、FORTRAN コンパイラが一番発達していて、C++ なんか下の下。まと >> もに使えるコンパイラがほとんど存在しない並列マシンだって機種によっては >> あるんです。実際需要がほとんどないですからね。 なんか、典型的な「列車ダイヤのパラドックス」というやつですね。使 う方は、 Fortran コンパイラしかないからどうしても並列機を使いたい 人はしょうがなく Fortran でかく、そうでない人は使わないという状況 もあるわけですから。 牧野＠東大駒場