[jfriends-ml 10929] Re: Doug Lea 本

[The Murayama <locutus@xxxxxxxxxxxxxxxx>]

村山@NETGENEです．


> # 新人教育ではやることが多過ぎて、とてもマルチスレッドまで
> # 踏み込めない・・・
＃昨日もあの時間にお帰りですか？
＃こっちも少々意識朦朧としながら書いてます．おかげで文章が．．．

> これはマルチプロセッサ機での話と思われますが、疎結合分散環境での並列処理も
> 「並列プログラミング」に含まれるのでしょうか？（素朴な疑問）
> # そういえば最近グリッドコンピューティングという言葉が飛び交っています
かなり微妙です．

密結合の共有メモリマシンやワンチップ=マルチプロセッサなら明らかに並列処理では
あっても分散処理ではないと思いますが，分散メモリマシンやパソコンを繋いで自作
したような並列マシンでは，はたして並列なのか分散なのかは明らかではありません．
これは「並列」(concurrent)と「並行」(parallel)でも同様です．

で，こういう疑問に対しては，大抵は
「『分散環境』で実行するのが分散処理．(分散メモリ)並列マシンで実行するのは並列処理．」
というふうに答えることが多いです．

＃もっと言えば，作った本人が「高速化を目的とした並列処理」と思っていれば並列で，
＃そうでない「分散環境」と思っていれば分散という区別もありえます．(^^;

もっとも分散メモリマシンでの並列プログラミングと，分散環境でのプログラミング
とは共通する部分も多いとは思いますし，境界域まで来ると本質的には差が無いので
「どっちでもいい」という扱いをされることが多いです．

> 世の中全ては分かりかねますが、マルチプロセッサ機で並列度を上げて処理速度を
> 向上させよう、というニーズはそれほど多くないかと思います。用語として並列
> プログラミングといっていても、実は処理の単純化で使用していることが多いのか
> と思います。
ですかね．
これは用語としては誤用だと思うのですが．

> 処理の高速化で使用したい分野で思いつくものとしては、
> シミュレーション分野や解析（数値計算）分野でしょうか。

高速化したいとなると，やっぱり

核兵器の開発，流体シミュレーション(航空力学，自動車の空気抵抗，潜水艦のスクリュー
の設計等？)，天気予報(流体シミュレーションの一種？)，自動車の強度計算(衝突時の
衝撃吸収)，蛋白質の立体構造予測やマルチプルアラインメント，

などの分野など，あるにはあるようなんですが日常的に使う例は少ないです．
＃鶏と卵の部分もあると思うけど．
あとはCGなんかを日常的に「作ってる」人．あの手のものは並列化が用意なので，
2CPUにすればほとんど2倍の性能が出るらしいです．

日常的に使う例が少ない理由の一つは，やはり並列プログラミングが難しいことと，
ここしばらくはシングルCPUの(具体的にはPentiumとAthronの)性能向上とコスト
ダウンが著しかったので，並列専用マシンがコスト的に劣勢に立たされてたことが
大きいと思います．
＃あと，東西冷戦の終結と米国の軍事予算削減の影響もかなり出てます．(^^;
＃核兵器開発用の受注が減ったでしょうから．

それに，それだけの性能を必要とするアプリケーションも少ないですしね．
今やWindowsとOffice，それにゲームが重いソフトの代名詞です．

>計算結果（データ）が影響を受けると結果が間違うことになりますね。
この辺が微妙な所です．問題領域や設計によります．
ただ並列プログラムでは，こういう非決定性を含むように作ることが多いです．


・計算結果が同じでも過程が同じとは限りません．
処理が早く進んでいる部分と遅れている部分があれば，進んでいる部分に
その分負荷を増やすようなこともあります．

・このようなシミュレーションには誤差が付き物ですが，厳密に
誤差まで同じにする必要は必ずしもありません．

誤差を若干許容することで性能が上がるならそうするでしょう．

・モンテカルロ法みたいなアルゴリズムの場合では，決定的に動作させること
にはほとんど意味はないでしょう．途中の処理順序が変わることでそこで使用
される乱数列が変われば，結果も変わったりするでしょう．

焼き鈍し法や遺伝的アルゴリズムなんかもこのタイプだと思います．
あくまで確率的に処理するので，決定的な動作は求められていません．
逐次で実行する場合には「疑似乱数」が完全に予測可能，つまり真の意味では
ランダムではないために動作は決定的になる場合もありますが，並列では
これが本当のランダムに近くなります．

・チェスやオセロのプログラム．
一つの考え方としては「勝ちさえすれば一手差でもなんでも構わない」というのが
あります．この場合は，答は一つとはならず，複数の解がありえます．各CPUに
それぞれ異なる初期条件をランダムで与えてから処理を開始させ，一番早く見つ
かった答を最終的な答とする，という方式が考えられます．複数ある答のうち，
どの答が出るかを決定的にする必要はありません．

これが「勝てる可能性のある全ての手を示す」とか「最も有利な形で勝たなければ
ならない」となれば，この場合は答は一つしかなくなってきますが，その場合は
現実的な時間では結果が出ない場合も多い．

最適化問題ってのは，得てしてこういうもんじゃないでしょうか．
特に並列にしてでも解きたい物の中には，現実的な計算時間では処理できない
ものも少なくない．

・チケットの申込み等を先着順で．
普通はこういうことをやりませんが，こういうことがもしあれば，AとBが
ほぼ同時にアクセスしても，どちらが先に処理されるかで結果は変化します．
先に処理された方のみがチケットを購入できる．


--------

並列処理を一番日常的に使ってるとすれば，ServletやJSPの世界でしょう．
ユーザー数が増えればCPU数を増やすことで簡単に高速化できます．

これの場合は，
・JSPやServletは可能な限りステートレスに作ることで，並列でありながら
各スレッド間の相互作用を最小限に押さえるように設計する．

・その他のJavaクラスは他スレッド(リクエスト)とは関係しない．

・スレッド間で影響する同期を取る必要のある部分は，Tomcatなどのレベルに
カプセル化する．

ということになるんだと思います．

Tomcatが同期やらをやってくれるおかげで，JSPやServletレベルでプログラムを
書く限り，同期やパフォーマンスの話はほとんど心配しなくて済みます．

それとServlet/JSPの分野は，各処理はお互いにほとんど独立しているという特徴
があります．それこそAさんのリクエストに対する処理と，Bさんのリクエストに
対する処理はお互いに影響してはいけないですよね．Aさんの処理だけを見ると
ほとんど完全にシングルスレッドで動作しているのと等価であり，Bさんの処理に
影響することは，ほとんどの場合バグになります．

でもこういう場合でも，実は必ずしも動作は決定的ではありません．

AさんとBさんが全く同時にアクセスして，先着順で顧客IDをつけていくとしたら，
Aさんを先に処理するかBさんを先に処理するかで結果が異なります．

さらに抽選で1名様に豪華プレゼントがあたるとして，それを顧客IDで決めると
すれば？結局は最初の同時アクセス時の処理によって，だれにプレゼントが
贈られるかという結果も変化します．