中村和志＠神戸です。

In article <YAS.03Nov23014119@kirk.is.tsukuba.ac.jp>
yas@is.tsukuba.ac.jp writes:
># 情報系としては非常に阿呆な質問をする事をお許し下さい。

"S"MPなら、新城さんの言うようにスレッドで処理すりゃ良いでしょ、で
済んで阿呆な質問なのですが、これが、

In article <86n0aku45o.wl@xh6.cc.hokudai.ac.jp>
reo@cc.hokudai.ac.jp writes:
>ここでふと疑問に思ったのですが、例えば SGI Onyx のように、1ノード
>4CPUで、16程度のノードで構成されている計算機がありますよね。

このような"S"MPでないMPマシンとなると、途端に話が難しくなります。
実在したトポロジだけでも、nCUBE,Hyper-Tree,トーラス…。
トランスピュータなんかは大抵、２次元格子ですよね。

In article <YAS.03Nov26013556@kirk.is.tsukuba.ac.jp>
yas@is.tsukuba.ac.jp writes:
>Pthreads と MPI を混ぜるのは、どうかなあ。

fj.comp.databasesにタイムリに挙がっているトランザクションの話題
とも共通しますが、ロックなり同期なりを、マルチプロセッサ、それも
非対称構成で、効率的、かつ安全に実装するのは頭痛のネタです。

>その点、最近のまともな SMP (まともでないものはのぞく)は、ス
>レッドでプログラムを書くと、けっこう CPU の数で性能が上がる
>プログラムは書きやすいです。SMP だけしか相手にしないなら、ス
>レッドの方が簡単です。

同感。ただし、SMPはリニアに性能向上が期待できる規模の並列マシン
しか作られていないのでは？たいていメモリ帯域やキャッシュの
コヒーレンシで頭打ちになるので、256PE以上の規模の"S"MP
マシンって実用になっていないような。LinuxのSMP回りも16PE
以下の規模しか基本的に想定していないですよね。

>少ないと思うんだけど、これは背景によるのかなあ。一応、SMP の
>ウリは、プログラミングが簡単ということには、なっていたんだけ
>ど。その昔は。

今もそうだと思います。GNU(hurd)も、普通に作った／既に作られている
ソースでも、スレッドライブラリをリンクするだけで、ライブラリ
レベルで実行可能な範囲で、並列動作してくれる、みたいなことを
狙っているようですし。MPIとかになると、プログラマがマシンや
ネットワーク構成を意識する必要が出て来るケースが多いと思います。

＃挙げ句の果てに、問題の方をマシン構成に向いたものを探して来る
＃ようになる本末転倒。＜かつての俺だ。

ところで、"p"threadって使いにくくないですか？セマンティックスが
素直な発想で構築されていると思うのだが、いざ使ってみると何だか
使いにくいことが多い。結局、Solarisにせよ、Linuxにせよ、POSIX
threadに何らかの拡張を施していますよね。
-- 
中村和志＠神戸         <mailto:kaz@kobe1995.net>
NAKAMURA Kazushi@KOBE   <http://kobe1995.net/>
- Break the hate chain. No more kill!
administrator@127.1