河野真治 @ 琉球大学情報工学です。

In article <YAS.03Sep6033214@kirk.is.tsukuba.ac.jp>, yas@is.tsukuba.ac.jp (Yasushi Shinjo) writes
> 昔、Luna88k という共有メモリのマルチプロセッサを使っていまし
> たが、割込みは、CPU#0 しか受付けなかったような気がします。タ
> イマ割込みをのぞいて。（いや、標準の Mach じゃなくて、自分で
> 作った手抜きＯＳだったのかもしれない。）

このあたりは、割込みコントローラの問題ですよね。Linux はどう
だったかな。割込みのベクタは両方のCPUで共有だったような気が
する。どっちにいってもだいじょうぶなように設計するのは割りと
簡単だし、OS的にも楽かな。

> ておくというのが、Sequent Dynix の定石でした。たとえば、12
> CPU なら、アプリケーションでは、11 個だけ使うようにすると、
> 速かったです。

一つあけておくってのは、Sun でも使えるテクニックだったと思い
ます。

> ３倍か。昔は、100倍くらいだったから、すごいですね。３倍とい
> うと、キャッシュとメモリの速度差より小さいですよね。

メインメモリがCPUから遠くなったからですよね。

でも、UMAは、しょせんスケーラビリティはないと思う。どうせ、
分散アルゴリズム的にいろいろやるならUMAである必要はないから。
配列でしかプログラムできない人達のためのものなんだと思います
ね。現実には、そういうアプリケーション(というか、数値計算)
が多いんでしょうけど。

> 共有メモリの共有のセマンティクスは、どうなっているんでしょう
> か。同期処理と一体化したようなもの(たとえばrelease
> consistency)は、使われているんでしょうか。

UMAっていう時には共有のセマンティクスはなくて、みんなで書き
込むとどうなるかわからないってものだと思います。

Sequent は、なんかlock機構が入っていたと記憶します。アクセス
する前に、なんかのマクロを呼ぶみたいな方法ですね。共有メモリ
に変なセマンティクスをいれてなんとかするってのは、僕はあんま
り良い方法だとは思わない。同期機構は分割統治を意識して、
少数で共有された多数の同期機構を用いるのが良いはずです。
分割手法のないロック機構はだめだと思う。

> Java をマルチスレッドで走らせて、ちゃんと走るんでしょうか。

それは、また、別な問題ですよね。ちゃんとってのがパフォーマンス
が出るかって問題だとすると言語的にも実装的にも難しいんですよね。
共有されているオブジェクトを Reference counting でGCするような
実装で、何も考えずにパフォーマンスが出るSMPを作れってのは、
ちょっと勝手すぎると思う。

---
Shinji KONO @ Information Engineering, University of the Ryukyus, 
              PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科, 
           科学技術振興事業団さきがけ研究21(機能と構成)