parallel

Hasegawa

unread,

Apr 4, 1996, 3:00:00 AM4/4/96

to

長谷川です。初めて投稿します。

「超並列」のパラダイム（日経サイエンス、９３年８月）

を読んで、さらに詳しく並列計算を勉強したいと思いました。

あまり、計算機には詳しくないので、そういう人のための
並列計算機の解説、教科書などを教えて下さい。

また、数値計算等にどのように利用されているかも
知りたいので、特に「流体計算」等の応用に関する
文献もご存じの方がおられたら、教えて下さい。
宜しく、お願いします。

長谷川
e-mail , hase...@ile.osaka-u.ac.jp

Akio Tokaji

unread,

Apr 5, 1996, 3:00:00 AM4/5/96

to

戸梶＠富士通です。

> 「超並列」のパラダイム（日経サイエンス、９３年８月）
>
> を読んで、さらに詳しく並列計算を勉強したいと思いました。
>
> あまり、計算機には詳しくないので、そういう人のための
> 並列計算機の解説、教科書などを教えて下さい。

私が、fj.lang.lisp で紹介した書籍をまずあたってみて下さい。
それと、私が開発した Mick-Lisp (Lisp for the MICro Kernel)
を使うと勉強するのに役に立つでしょう。

> また、数値計算等にどのように利用されているかも
> 知りたいので、特に「流体計算」等の応用に関する
> 文献もご存じの方がおられたら、教えて下さい。
> 宜しく、お願いします。

以下の本をとりあえずお薦めします(参考文献も出てます)：

『数値予報(スーパーコンピュータを利用した新しい天気予報)』、
岩崎俊樹著、共立出版(情報フロンティアシリーズ、情報学会編)

数値予報のしくみ／観測データから初期条件をつくる／数値
気象情報をどう使う／他

--
/**********************************************************************
* Akio TOKAJI (tok...@db.nm.fujitsu.co.jp) / Fujitsu Limited
*
* "Imagination is more important than knowledge"
* (fortune cookie's message)
**********************************************************************/

Akio Tokaji

unread,

Apr 5, 1996, 3:00:00 AM4/5/96

to

訂正です。

> 以下の本をとりあえずお薦めします(参考文献も出てます)：
>
> 『数値予報(スーパーコンピュータを利用した新しい天気予報)』、
> 岩崎俊樹著、共立出版(情報フロンティアシリーズ、情報学会編)

↑
情報処理学会編

Jun Shirakura

unread,

Apr 6, 1996, 3:00:00 AM4/6/96

to

In article <TOKAJI.96...@zaurus.db.nm.fujitsu.co.jp>,

tok...@db.nm.fujitsu.co.jp (Akio Tokaji) wrote:
> > あまり、計算機には詳しくないので、そういう人のための
> > 並列計算機の解説、教科書などを教えて下さい。
>
> 私が、fj.lang.lisp で紹介した書籍をまずあたってみて下さい。
> それと、私が開発した Mick-Lisp (Lisp for the MICro Kernel)
> を使うと勉強するのに役に立つでしょう。

こんにちは。白倉と申します。
お話の途中ですが、割り込ませてください。

並列計算機の解説について問うている人にLISPについての本を薦めるのは
どのような考えから来るものでしょうか。
また、戸梶さんのMick-Lispを勉強にお勧めするのはどういうわけなのか、
Mick-Lispの特徴などを簡単に説明してから、教えてくださいませんか。

もともとの投稿はfj.sci.physicsに投稿されているところから見て、
物理の人かららしいのですが、そういう人に、Lispを教えようとするのは、
現在の状況からかなりかけ離れています。現状では、FORTRANかCの
並列化ベクトル化コンパイラを使うのが一般的だからです。
このような点についてもコメントをいただけるとありがたいです。
おねがいします。＞戸梶さん

それでは。

--
Jun Shirakura
Dept. of Biophysical Engineering,Facluty of Engineering Science,
Osaka University
j...@po.aianet.or.jp,sira...@bpe.es.osaka-u.ac.jp

Akio Tokaji

unread,

Apr 6, 1996, 3:00:00 AM4/6/96

to

戸梶＠富士通です。

白倉さん、はじめまして。

> もともとの投稿はfj.sci.physicsに投稿されているところから見て、
> 物理の人かららしいのですが、そういう人に、Lispを教えようとするのは、
> 現在の状況からかなりかけ離れています。現状では、FORTRANかCの
> 並列化ベクトル化コンパイラを使うのが一般的だからです。
> このような点についてもコメントをいただけるとありがたいです。

＃(多分)長いコメントツリーになると思います。

まずは、キーワードとして、「超」並列となっていたこともあります。

それから、超並列というと、ニューロコンピューティングまたは、A-Life
とか絡むかなぁと思ったんですけど。
(『コネクションマシン』(パーソナルメディア刊)って御存知ですか？)

どうして「現状では、FORTRANかCの並列化ベクトル化コンパイラを使うの
が一般的」と言えるのですか？これは(応用)分野や、プロセッサの粒度
を問わずということでしょうか？

Jun Makino

unread,

Apr 6, 1996, 3:00:00 AM4/6/96

to

>>>>> On 06 Apr 1996 09:10:58 GMT, tok...@db.nm.fujitsu.co.jp (Akio
Tokaji) said:

>> もともとの投稿はfj.sci.physicsに投稿されているところから見て、
>> 物理の人かららしいのですが、そういう人に、Lispを教えようとするのは、
>> 現在の状況からかなりかけ離れています。現状では、FORTRANかCの
>> 並列化ベクトル化コンパイラを使うのが一般的だからです。
>> このような点についてもコメントをいただけるとありがたいです。

> まずは、キーワードとして、「超」並列となっていたこともあります。

> それから、超並列というと、ニューロコンピューティングまたは、A-Life
> とか絡むかなぁと思ったんですけど。
> (『コネクションマシン』(パーソナルメディア刊)って御存知ですか？)

もとのポストは流体計算とかにという話だったので、あんまりニューロ
コンピューティングとか、A-Life とかは関係ないのではないかとも思う
のですが、いかがでしょう。それと、 CM であればそれこそ CM-Fortran
みたいな言語を使うのが今は「一般的」ではないかという気もしますが、
どんなものでしょうか。10 年前なら CM を使おうと思えば *Lisp なん
てものを使うしかなかったのですが。

> どうして「現状では、FORTRANかCの並列化ベクトル化コンパイラを使うの
> が一般的」と言えるのですか？これは(応用)分野や、プロセッサの粒度
> を問わずということでしょうか？

「物理」、特に「流体計算」という分野に関する話でしょうね。

牧野＠東大駒場

Akio Tokaji

unread,

Apr 6, 1996, 3:00:00 AM4/6/96

to

戸梶＠富士通です。

牧野＠東大駒場さん、

> > どうして「現状では、FORTRANかCの並列化ベクトル化コンパイラを使うの
> > が一般的」と言えるのですか？これは(応用)分野や、プロセッサの粒度
> > を問わずということでしょうか？
>
> 「物理」、特に「流体計算」という分野に関する話でしょうね。

(1) 例えば、ある３次元空間を、10 x 10 x 10 の格子に区切って、その各交
点である演算(f(x,y,z))をするとした場合に、FORTRAN またはＣでは、
どのようなコードになりますか？ (1000個の交点ができますよね。x,y,z
は、それぞれ、0～9 までの座標軸上の値を取ります)

(2) 同じく、10 x 10 x 10 の格子の各交点で、f(x,y,z) が、0～n 個の数値
を返す時に、1000個の各ノードからの値をつなぎあわせた一覧をメモリ上
に作るには、どのようなコーディングをしますか？

Jun Makino

unread,

Apr 6, 1996, 3:00:00 AM4/6/96

to

>>>>> On 06 Apr 1996 14:06:02 GMT, tok...@db.nm.fujitsu.co.jp (Akio Tokaji) said:

>> 「物理」、特に「流体計算」という分野に関する話でしょうね。

> (1) 例えば、ある３次元空間を、10 x 10 x 10 の格子に区切って、その各交
> 点である演算(f(x,y,z))をするとした場合に、FORTRAN またはＣでは、
> どのようなコードになりますか？ (1000個の交点ができますよね。x,y,z
> は、それぞれ、0～9 までの座標軸上の値を取ります)

えっと、質問の意図がわかりませんが、、、もしよろしければ現状で何
が一般的かという話と、上の質問との関係を御説明いただけないでしょ
うか。

牧野＠東大駒場

Akio Tokaji

unread,

Apr 6, 1996, 3:00:00 AM4/6/96

to

戸梶＠富士通です。

> えっと、質問の意図がわかりませんが、、、もしよろしければ現状で何
> が一般的かという話と、上の質問との関係を御説明いただけないでしょ
> うか。

まず(とりあえず)以下のあたりの文献／情報などを参照してみて下さい。
common understanding というものが必要でしょう？参考文献／ポインタ
を示してから、客観的に話をするというのも大切ですからね。

＃それと、プログラミングに関する素養(理論も含む)も付けといて下さい。

●文部省重点領域研究「超並列原理に基づく情報処理基本体系」シンポジ
ウム予稿集 (平成４年９月24日～25日、＠東京大学)

●情報処理 Apr. 1991(Vol.32, No.4) 「特集超並列マシンとその応用」
(情報処理学会)

●並列記号処理，柴山潔著, コロナ社

●コネクションマシン、ダニエル・ヒリス著／喜連川優訳、パーソナル
メディア

牧野＠東大駒場さんが、私とどういうお話がしたいのかが、よく分りません。
興味の対象とかを示してくれれば、対応のしかたについては考慮させていた
だきます。それと、牧野さんの論拠となっている文献なども挙げていただけ
れば助かります。

Jun Shirakura

unread,

Apr 7, 1996, 4:00:00 AM4/7/96

to

In article <TOKAJI.96...@zaurus.db.nm.fujitsu.co.jp>,
tok...@db.nm.fujitsu.co.jp (Akio Tokaji) wrote:

> (『コネクションマシン』(パーソナルメディア刊)って御存知ですか？)
知っています。読みました。

> どうして「現状では、FORTRANかCの並列化ベクトル化コンパイラを使うの
> が一般的」と言えるのですか？これは(応用)分野や、プロセッサの粒度
> を問わずということでしょうか？

物理学の分野においては、そうだと思います。
プロセッサの粒度がどうであろうと、商用のマシンにおいては、vpp,AP1000
などのように、まず、C,FORTRANの実装を行っていると思います。そういう点で
並列計算機の専門家でない人々がまず使うのは、C,FORTRANですので、あのように、
書いたわけです。
実は、超並列計算機の現状について議論する気はあまりなく、本当に聞きたいのは
以下の質問の答えです。

> 並列計算機の解説について問うている人にLISPについての本を薦めるのは
> どのような考えから来るものでしょうか。
> また、戸梶さんのMick-Lispを勉強にお勧めするのはどういうわけなのか、
> Mick-Lispの特徴などを簡単に説明してから、教えてくださいませんか。

僕は商用の並列計算機で、Lispをメインの言語に使っていたものは、CMしか、
知りません。ですから、少し疑問に思ったわけです。
研究段階にあるものはたくさんあると思いますし、僕の興味でもあります。
よろしくお願いします。

Akio Tokaji

unread,

Apr 7, 1996, 4:00:00 AM4/7/96

to

戸梶＠富士通です。

> > ＃それと、プログラミングに関する素養(理論も含む)も付けといて下さい。
>
> 私のあれだけの文章から「こいつにはプログラミングに関する素養がな
> いらしい」と判断される勇気には敬服します。

>
> > 牧野＠東大駒場さんが、私とどういうお話がしたいのかが、よく分りません。
> > 興味の対象とかを示してくれれば、対応のしかたについては考慮させていた
> > だきます。
>

> 戸梶さんとの議論に関していえば、私の現在の興味は、「この戸梶さん
> という人は、大規模数値計算、あるいは High Performance Computing
> といったものの現状について知ったうえで議論しているのだろうか」と
> いうことです。議論するにはcommon understanding というものが必要だ
> ということのようですから。

いちおう、私が目標としている所を紹介します。

(1)(例えば)AP1000/AP3000 のような超並列型コンピュータをとことん
酷使したい。

確認ですが、
いわゆるスーパーコンピュータ(ベクトルプロセッサ)ではなくて、超並列マ
シンの話をしているんですよね？
超並列マシンまたは、(High Performance Computing の中でも)超並列計算の
ことについての common understanding が必要だと言ってます。

＃超並列に関しては、(もしかしたら) 現在(現状)というようりは、これから
＃花開く分野なのではないでしょうか？

Jun Makino

unread,

Apr 7, 1996, 4:00:00 AM4/7/96

to

>>>>> On 07 Apr 1996 08:51:24 GMT, tok...@db.nm.fujitsu.co.jp (Akio
Tokaji) said:

>> 戸梶さんとの議論に関していえば、私の現在の興味は、「この戸梶さん
>> という人は、大規模数値計算、あるいは High Performance Computing
>> といったものの現状について知ったうえで議論しているのだろうか」と
>> いうことです。議論するにはcommon understanding というものが必要だ
>> ということのようですから。

> いちおう、私が目標としている所を紹介します。

> (1)(例えば)AP1000/AP3000 のような超並列型コンピュータをとことん
> 酷使したい。

戸梶さんの目標が、High Performance Computing の現状とは無関係なも
のであるということは良くわかりました。

> 確認ですが、
> いわゆるスーパーコンピュータ(ベクトルプロセッサ)ではなくて、超並列マ
> シンの話をしているんですよね？

そうなんですか？前に書かれた

戸梶さん：

>> > どうして「現状では、FORTRANかCの並列化ベクトル化コンパイラを使うの
>> > が一般的」と言えるのですか？これは(応用)分野や、プロセッサの粒度
>> > を問わずということでしょうか？

牧野：
>> 「物理」、特に「流体計算」という分野に関する話でしょうね。
戸梶さん：

> (1) 例えば、ある３次元空間を、10 x 10 x 10 の格子に区切って、その各交
> 点である演算(f(x,y,z))をするとした場合に、FORTRAN またはＣでは、
> どのようなコードになりますか？ (1000個の交点ができますよね。x,y,z
> は、それぞれ、0～9 までの座標軸上の値を取ります)

> (2) 同じく、10 x 10 x 10 の格子の各交点で、f(x,y,z) が、0～n 個の数値
> を返す時に、1000個の各ノードからの値をつなぎあわせた一覧をメモリ上
> に作るには、どのようなコーディングをしますか？

というのは、「超並列マシンの話」だったのですか。戸梶さんのお話は
高度過ぎて、私には理解できないようです。私はまた、並列処理言語の
話かと思っておりました。

> 超並列マシンまたは、(High Performance Computing の中でも)超並列計算の
> ことについての common understanding が必要だと言ってます。

そうですね。例えば「風洞」という言葉をご存知でない方とは流体計算
の議論をするのは難しいというのと同じようなことでしょうか。（参照：
<TOKAJI.96M...@zaurus.db.nm.fujitsu.co.jp>）

> ＃超並列に関しては、(もしかしたら) 現在(現状)というようりは、これから
> ＃花開く分野なのではないでしょうか？

なるほど、現在の実用レベルの話をなさっているのではないということ
ですね。それならおっしゃりたいことは良くわかります。個人的には、
例えば MIT の G. Sussman とかがずーっとやっている、 Scheme を科学
技術計算の実用に使えるようなものにしていこうという努力は重要なも
のだとは思います。

ま、それでも、 Gordon Bell 賞でもとろうという時には C で書いてし
まうというあたりはちょっとしょうがないですが。(参照：
http://www.supercomp.org/sc95/proceedings/722_PSKO/SC95.HTM)

牧野＠東大駒場

Akio Tokaji

unread,

Apr 8, 1996, 3:00:00 AM4/8/96

to

戸梶＠富士通です。

> 場合によってソースプログラムを書き換えないといけないくらいなら、
> Fortran で3重ループを書いたものをコンパイラが自動並列化するほうが
> より「透過的」であるような気もするのですが、どんなものでしょうか？

＃頭が完全に「素ベクトルマン」になってませんか？

機能セルを使った、超マイクロカーネル＆超細粒度マシン(Lispマシンとも
いう？)だと、インタプリティブながら超高速に動作する設計になってます。

遠いかどうかは別として、期待していて下さい。

Kazunori Sugiyama

unread,

Apr 8, 1996, 3:00:00 AM4/8/96

to

<hasegawa-040...@mcs2.ile.osaka-u.ac.jp>の記事において
hase...@ile.osaka-u.ac.jpさんは書きました。

>> 長谷川です。初めて投稿します。

>>
>> 「超並列」のパラダイム（日経サイエンス、９３年８月）
>>
>> を読んで、さらに詳しく並列計算を勉強したいと思いました。
>>

>> あまり、計算機には詳しくないので、そういう人のための
>> 並列計算機の解説、教科書などを教えて下さい。
>>

洋書ですが、

Title : Parallel Computing Theory and Practice 2/E
Author: Michael J. Quinn
Publisher: McGraw Hill

この本は良くまとまっていると思います。

杉山＠京大

Jun Makino

unread,

Apr 8, 1996, 3:00:00 AM4/8/96

to

>>>>> On 08 Apr 1996 07:15:24 GMT, tok...@db.nm.fujitsu.co.jp (Akio
Tokaji) said:

> 戸梶＠富士通です。
>> 場合によってソースプログラムを書き換えないといけないくらいなら、
>> Fortran で3重ループを書いたものをコンパイラが自動並列化するほうが
>> より「透過的」であるような気もするのですが、どんなものでしょうか？

> ＃頭が完全に「素ベクトルマン」になってませんか？

人がわざわざ「自動並列化」と書いてあげているのに、、、データパラ
レル型との比較について触れていただけなかったのは残念です。

> 機能セルを使った、超マイクロカーネル＆超細粒度マシン(Lispマシンとも
> いう？)だと、インタプリティブながら超高速に動作する設計になってます。

なるほど、

>> | Message-ID: <TOKAJI.96M...@zaurus.db.nm.fujitsu.co.jp>
>> | ということで、Mick-Lisp は、逐次実行と、並列処理との間が「スムーズ」ま
>> | たは「透過的」で、プロセッサの粒度やネットワークのトポロジーに関係なく、

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>> | または、そのようなことを意識せずにコーディング／実行ができるような、言
>> | 語(体系)およびＯＳが必要だと思ったんです。

という理想からはほんとに遠いのですね。あまり期待しないことにしま
す。

牧野＠東大駒場

Akio Tokaji

unread,

Apr 8, 1996, 3:00:00 AM4/8/96

to

戸梶＠富士通です。

> > (1) 例えば、ある３次元空間を、10 x 10 x 10 の格子に区切って、その各交
> > 点である演算(f(x,y,z))をするとした場合に、FORTRAN またはＣでは、
> > どのようなコードになりますか？ (1000個の交点ができますよね。x,y,z
> > は、それぞれ、0～9 までの座標軸上の値を取ります)
>
> > (2) 同じく、10 x 10 x 10 の格子の各交点で、f(x,y,z) が、0～n 個の数値
> > を返す時に、1000個の各ノードからの値をつなぎあわせた一覧をメモリ上
> > に作るには、どのようなコーディングをしますか？
>
> というのは、「超並列マシンの話」だったのですか。戸梶さんのお話は
> 高度過ぎて、私には理解できないようです。私はまた、並列処理言語の
> 話かと思っておりました。

Mick-Lisp は、並列処理言語です。逐次処理マシン、ベクトルプロセッサ、
および並列処理マシン向けに、並列処理の計算の進み方を明示的かつ容易
に指定可能です。

●(1)のコーディング例

逐次処理の場合(1-a)：

(dim ((x 10)(y 10)(z 10)) (f x y z))

超並列処理の場合(1-b)：

(dim* ((x 10)(y 10)(z 10)) (f x y z))

●(2)のコーディング例

[2-a]:
(concat-dim ((x 10)(y 10)(z 10)) (f x y z))

[2-b]:
(concat-dim* ((x 10)(y 10)(z 10)) (f x y z))

一般に、f(x,y,z)のコストが小さい場合には、直列に(またはパイプライン
処理で)実行した方が良い場合があるので、[1-a]、[2-a] を選択して下さい。

逆に、f(x,y,z)の計算時間が大きい場合には、[1-b]、[2-b] の記法を使って
下さい。各交点に対して、f(x,y,z) という式およびパラメータをブロードキ
ャストすることにより、完全に並列に処理が行われます。

＃Fortran, C へのトランスレータは現在開発中です。

Jun Makino

unread,

Apr 8, 1996, 3:00:00 AM4/8/96

to

>>>>> On 08 Apr 1996 11:07:22 GMT, tok...@db.nm.fujitsu.co.jp (Akio Tokaji) said:

> 戸梶＠富士通です。

>> 人がわざわざ「自動並列化」と書いてあげているのに、、、データパラ
>> レル型との比較について触れていただけなかったのは残念です。

> ＃書いてくれてるんですか？

そうです。

> このあたりの記述を叩き台にしましょうか。

いえ、けっこうです。戸梶さんになにかを聞いてもまったく答えていた
だけないことと、戸梶さんの頭のなかには時代遅れの本から得た知識し
かないらしいということがよくわかりましたので、申し訳ありませんが
これ以降戸梶さんの記事にはフォローしないことにします。

が、まあ、ひとことだけ

> |●コネクションマシン、ダニエル・ヒリス著／喜連川優訳、パーソナル
> | メディア

ううん、私は多分 CM の日本ではもっとも初期のユーザーだと思うんだ
が、、、それはまあそれとして、

というわけで TMC は倒産したとはいえ CM-2, CM-5 などの興味深いハー
ドウェアと、 *Lisp, C*, CM-Fortran などの優れた並列処理言語を開発
し、その後の並列処理研究に大きな影響を与えたわけですが、戸梶さん
はその辺のことをどのくらいご存知なのか、、、

牧野＠東大駒場

Jun Shirakura

unread,

Apr 8, 1996, 3:00:00 AM4/8/96

to

In article <TOKAJI.96M...@zaurus.db.nm.fujitsu.co.jp>,
tok...@db.nm.fujitsu.co.jp (Akio Tokaji) wrote:

> ということで、Mick-Lisp は、逐次実行と、並列処理との間が「スムーズ」ま
> たは「透過的」で、プロセッサの粒度やネットワークのトポロジーに関係なく、

> または、そのようなことを意識せずにコーディング／実行ができるような、言
> 語(体系)およびＯＳが必要だと思ったんです。

In article <TOKAJI.96...@zaurus.db.nm.fujitsu.co.jp>,
tok...@db.nm.fujitsu.co.jp (Akio Tokaji) wrote:

> Mick-Lisp は、並列処理言語です。逐次処理マシン、ベクトルプロセッサ、
> および並列処理マシン向けに、並列処理の計算の進み方を明示的かつ容易
> に指定可能です。

In article <TOKAJI.96...@zaurus.db.nm.fujitsu.co.jp>,
tok...@db.nm.fujitsu.co.jp (Akio Tokaji) wrote:

> 機能セルを使った、超マイクロカーネル＆超細粒度マシン(Lispマシンとも
> いう？)だと、インタプリティブながら超高速に動作する設計になってます。

戸梶さんの言われていることは、非常に興味深く、僕のセンスとも合致するところ
が多いのですが、これらのことがMick-Lispで実際にインプリメントされているの
ですか？でしたら、詳細を知りたいので、論文があればそれが掲載されたものを
教えてください。
あなたが、これらのことを本当に実現させているのなら、すごいことだと思いま
すが、そうでないのなら、それほど声を大にして言うほどのこともないと思います。
なぜなら、これくらいのことならば、僕にも思いつくからです。
僕はすでにこれらのことをするためのアーキテクチャを考えていて、シミュレ
ータも作っています。本業の神経回路の仕事が忙しいので、論文にはしていま
せんが、そのうちするつもりです。しかし、論文にできるほどのことか僕には
確信がありません。

それでは。

Jun Makino

unread,

Apr 8, 1996, 3:00:00 AM4/8/96

to

>>>>> On 8 Apr 1996 12:38:07 GMT, a50...@sakura.kudpc.kyoto-u.ac.jp
(masayoshi kiguchi) said:

> 木口@近畿大学です。外野席から一言：
> 牧野さんの

> | どんなものでしょうか。10 年前なら CM を使おうと思えば *Lisp なん
> | てものを使うしかなかったのですが。

> のコメントを見て、感慨ひとしお。CM も、はや、10年ですか。

もうそうなるんですね、、、とはいえ TMC が倒産してからはや2年です
から。その後クレイが SGI に吸収され、インテルも事実上 MPP の商売
からは手を引くとなると、アメリカの High Performance Computing は
どうなっていくのかということは人事ながら気になりますね。

> 戸梶さんと牧野さんの話はかみあっていないけれど、

すみません、、、

> 計算機屋さんがこれから
> の計算機環境がどう変わっていくと考えているのかは知りたい所。

これはそうですね。

> この10年で super-computer の状況も様変りして、NSF(National Science
> Foundation, USA)の Super-computer Center program は来年の9月で終了、現
> 在の4つのセンターを廃止、年間 $65M の予算で, 新たに 1つ、ないし、2つの
> センターと幾つかの小規模センターの Partnership program に移行するとか
> で、その選考結果が来年2月に発表されるとか聞きました。

> Cray T3E のような機械で流体計算するのなら, Fortran Compiler を使って計
> 算すれば良いので、いまさら集中投資するようなものではないと思うのだけれ
> ど、なぜ今の時期に、USA の優位性を確保するためとか称して, 投資を集中す
> る必要があるのか気になる所です。

Supercomputing '95 での雰囲気では、「投資の集中」というよりは国庫
支出削減の一環というような感じもしました。要するに軍事費支出の削
減に伴い、純粋科学（「基礎研究」という言葉もありますが、天文学が
なにかの基礎かといわれると困るので）への支出も減ってきているとい
うことのあらわれのようにもみえます。

牧野＠東大駒場

Yukio Ishihara

unread,

Apr 9, 1996, 3:00:00 AM4/9/96

to

石原＠ザ・ランスです。
In article <4kb1bf$l...@kudpc.kudpc.kyoto-u.ac.jp>,
a50...@sakura.kudpc.kyoto-u.ac.jp says...
>
>戸梶さんと牧野さんの話はかみあっていないけれど、計算機屋さんがこれから
>の計算機環境がどう変わっていくと考えているのかは知りたい所。
>
超並列コンピュータなんて全く無縁の世界に住んでるもんで、ここのお話は
さっぱりわかってないんですが、しゃしゃり出てしまいました。
はじめ、お２人の対立点は
(1) 流体という物理現象（それがどんな流体であれ）を最先端の計算機を用
いることでどこまで解明できるかという物理学的興味
と
(2) （たとえば）流体のような非線形性が本質的な系を計算機でどこまで再
現できるかという計算機科学的興味
の違いにあるのかなと思ってたんですが、どうもそうじゃないようですね。
勿論、(1) と(2) は密接に結びついてて明瞭に切り離せるもんじゃないでし
ょうけど、興味の方向によってウェイトの置き方は変わってくるだろう。ちょ
っと「ニュートン力学」と「微積分学」の関係を連想してしまうんですが・・
私なんかは、もう少し (1)のほうのお話を伺いたいという気がしてます。

# でも、「風洞」も知らない人が参入して来るというのは、この分野も新しい
# 発展段階に入ろうとしてることの証しではないだろうか？
# ニュートンだけだったとこにライプニッツが現れた、と考えるのは無理があ
# りますか？ (^^;

<Yukio Ishihara of theR.A.N.S.>
yuki...@sh0.po.iijnet.or.jp

Yukio Ishihara

unread,

Apr 12, 1996, 3:00:00 AM4/12/96

to

石原＠ザ・ランスです。
In article <MAKINO.96A...@muscat.c.u-tokyo.ac.jp>,
mak...@chianti.c.u-tokyo.ac.jp says...

>
>> # でも、「風洞」も知らない人が参入して来るというのは、この分野も新しい
>> # 発展段階に入ろうとしてることの証しではないだろうか？
>

>やはり、この分野というよりも、 fj というものが（それがいいか悪い
>かはまた別問題ですが）新しい発展段階にはいっているのではないかと
>いう気もします。戸梶さんは fj.net.misc, fj.lang.lisp, fj.sci.math
>
これって、「 fj は本来学術ネットなのであって、こういうヤカラに荒ら
されるのは迷惑だ」っていうふうに聞こえちゃうんですけど・・・

# 今日は二日酔いなもんで、下らない被害妄想で書いてるようでしたら
# ごめんなさい _o_

Jun Makino

unread,

Apr 15, 1996, 3:00:00 AM4/15/96

to

>>>>> On 15 Apr 1996 02:14:12 GMT, yuki...@sh0.po.iijnet.or.jp (Yukio
Ishihara) said:

> 「意味はある」ということだけでも認めて頂けて心強く思ってます。もっと
> も「擬似科学」と「擬似じゃない科学」の明確な境界ってどっかにあるのかど
> うか、私にはわからないので、教えて頂けると有り難いのですが。

「明確な境界」はないと思います。（これには異論がある人がいるとも
思いますが）

> それはともかく、こういう議論にも積極的な意味を見出したいと思うという
> のは、少なくとも私にとっては今回は結構収穫があったと思うからです。それ
> は「超並列コンピュータによる流体計算」という私にとっては全く未知の分野
> を探究されている、牧野さんはじめ多くの方々のお名前だけでも知り得たとい
> うことです（さすがに業績まではまだ充分に見えてないけど、それはしろうと
> に簡単にわかるもんじゃないでしょうから仕方ないか）。無論、積極的に調べ
> ればわかることなんだろうけど、ふつーそこまでしない者にとっては、小さく
> ない収穫でした。

すみません、、、私はちっとも「超並列コンピュータによる流体計算」
を探究しているわけではないので、誤解のないように、、、それでは何
を「探求」しているかというと、その昔は「ベクトル／並列計算機によ
る自己重力粒子系シミュレーション」ということをしておりまして、こ
このところは「ベクトル／並列計算機」が「専用計算機」に置き換わっ
ております。どんなことをやっているかは杉本大一郎編「専用計算機に
よるシミュレーション」, 1994, （朝倉書店、東京）をみていただけれ
ば、、、（と、これは一応「営利行為」ではないということになってま
すよね。）

> 余談ですが、「積極的に調べる」といえば（たいして積極的でもないんです
> が）ここで拝見した方々のお名前を手元にある「流体力学会」の名簿で探した
> んですが、見当たらないですね。皆さん「そんなマイナーな学会は無視」です
> か？(^^;

というわけで私は自分では流体計算はしていませんので、、、他の方の
多くは並列計算機のほうの専門家であるようです。

牧野＠東大駒場

Yukio Ishihara

unread,

Apr 15, 1996, 3:00:00 AM4/15/96

to

In article <MAKINO.96A...@muscat.c.u-tokyo.ac.jp>,
mak...@chianti.c.u-tokyo.ac.jp says...
>

>> でも、そうだとすると、これには積極的な意味もあるのかも知れない（たと
>> えば同じ分野の「仲間うち」では簡単に通じる論理が他の分野の人とは全く
>> （略）
>
> えっと、意味はあると思いますが、それは、石原さんのおっしゃるよう
> な分野間の壁といったようなことよりも、むしろ、例えば、「疑似科学」
> 的な話題をどのように扱うかということに近いのではないかと思います。

「意味はある」ということだけでも認めて頂けて心強く思ってます。もっと
も「擬似科学」と「擬似じゃない科学」の明確な境界ってどっかにあるのかど
うか、私にはわからないので、教えて頂けると有り難いのですが。

それはともかく、こういう議論にも積極的な意味を見出したいと思うという

のは、少なくとも私にとっては今回は結構収穫があったと思うからです。それ
は「超並列コンピュータによる流体計算」という私にとっては全く未知の分野
を探究されている、牧野さんはじめ多くの方々のお名前だけでも知り得たとい
うことです（さすがに業績まではまだ充分に見えてないけど、それはしろうと
に簡単にわかるもんじゃないでしょうから仕方ないか）。無論、積極的に調べ
ればわかることなんだろうけど、ふつーそこまでしない者にとっては、小さく
ない収穫でした。

余談ですが、「積極的に調べる」といえば（たいして積極的でもないんです

が）ここで拝見した方々のお名前を手元にある「流体力学会」の名簿で探した
んですが、見当たらないですね。皆さん「そんなマイナーな学会は無視」です

か？(^^; ↑
関係者の方、ごめんなさい_o_

で、私以外にもそういう人はいるんじゃないかと思うわけです。中には非常
に有能な人もいるかも知れない。そういう人が参入して来るかも知れないせっ
かくのチャンスなんだから、議論の品位は大事だと、議論の品位にはその人の
品位が反映するだろうと、（人の品位は周りが判断することだろうけど）少な
くともご自分を卑下するような言い方はやめて頂きたいと、お願いするわけで
す。

Yukio Ishihara

unread,

Apr 16, 1996, 3:00:00 AM4/16/96

to

In article <MAKINO.96A...@muscat.c.u-tokyo.ac.jp>,
mak...@chianti.c.u-tokyo.ac.jp says...
>

>すみません、、、私はちっとも「超並列コンピュータによる流体計算」
>を探究しているわけではないので、誤解のないように、、、それでは何

誤解しますよ、ここだけ読んでたら・・・
# ま、私が無知なだけなんでしょうけど。

>を「探求」しているかというと、その昔は「ベクトル／並列計算機によ
>る自己重力粒子系シミュレーション」ということをしておりまして、こ
>このところは「ベクトル／並列計算機」が「専用計算機」に置き換わっ
>ております。どんなことをやっているかは杉本大一郎編「専用計算機に
>よるシミュレーション」, 1994, （朝倉書店、東京）をみていただけれ

有り難うございます。折りがあれば読ませて頂きたいと思います。

でも、ちょっと古いですけど、「ながれ」10 (1991) に長澤幹夫「Smoothed
Partcle 法による宇宙気体力学」という解説記事を見つけました。牧野さんの

Koji Mori

unread,

Apr 18, 1996, 3:00:00 AM4/18/96

to

森＠淺沼です。

In article <MAKINO.96A...@muscat.c.u-tokyo.ac.jp> mak...@chianti.c.u-tokyo.ac.jp (Jun Makino) writes:

> >> > 「意味はある」ということだけでも認めて頂けて心強く思ってます。もっと
> >> > も「擬似科学」と「擬似じゃない科学」の明確な境界ってどっかにあるのかど
> >> > うか、私にはわからないので、教えて頂けると有り難いのですが。
> >>

> >> 「明確な境界」はないと思います。（これには異論がある人がいるとも
> >> 思いますが）
>
> > アプローチに本質的な違いがあると思います。
>
> 「明確な境界がない」ということと、「本質的な違いがある」というこ
> とは必ずしも矛盾することではないと思うのですが、森さんは「明確な
> 境界はある」とお考えですか？

グレーゾーンが存在するのではないかという意味なら、「明確な境界はない」
と私も思います。

ただ話の流れから考えて、石原さんの疑問が「擬似科学」と「疑似じゃない科
学」との間に(概念上の)明確な境界があるのかというところにあるのかな、と
思いましたので。
# 擬似科学かそうでないかをどのように判定するのにはどうしたらいいのだろ
# うかというニュアンスだったんじゃないでしょうか。私がそう思っただけか
# もしれませんが。

> 例えば「線形の現象」と「非線形性の効く現象」というのは「本質的な
> 違い」があると私は思いますが、「ここまでは線形」「ここからは非線
> 形」という明確な境界というものはないように思います。

現象を分類するという時点で明確な境界というのがぼやけるのだと思いますが、
完全に線形の現象ってありましたっけ?
# 少なくともモデル化したものについては明確な境界がありますよね。:-)
--
森浩二 (MORI Koji)
(株)淺沼組技術研究所
E-mail: mo...@asanuma.co.jp

Hiroshi Murakami

unread,

May 3, 1996, 3:00:00 AM5/3/96

to

<MAKINO.96...@muscat.c.u-tokyo.ac.jp>の記事において
mak...@chianti.c.u-tokyo.ac.jpさんは書きました。

>> どちらかというと「投資を集中」というよりは「統合による合理化」と
>> いう感じではないでしょうか？純粋科学関係の予算は削られる傾向でしょ
>> うから。それに、4つの独立したセンターを持つ意義はネットワークが発
>> 達した今では確かにちょっと薄いような気はします。

これは、仮にネットワークが発達すれば、日本でも計算機センターの
集中/淘汰が起きることを意味するでありましょうか？