hirax.net::Keywords::「並列化」のブログ



1999-12-30[n年前へ]

6502と並列計算とムーアの法則 

人間のクロック&スケールアップ


 「物理の散歩道」を読み直していると、とある文章に興味を覚えた。

  • 第五物理の散歩道 ロゲルギスト著 岩波新書
の中の「通信を考える」である。この本は、何度読み返しても新鮮である。

 「通信を考える」の中の興味を惹かれた部分は「信号の伝わる速度と距離と処理速度の関係」を論じている部分だ。例えば、計算機は処理速度を高めるためには回路の大きさを小さくしなければならないとか、人間の頭脳の働きの速さから集団生活の広がりの限界について論じているのだ。例えば、

  • 計算機の演算速度の時間スケール -> ナノ秒 = 10^-9s (クロックで考えると、1GHz)
  • 人間の演算速度の時間スケール -> サブ秒 = 10^-1s (クロックで考えると、10Hz)
ということから、計算機の大きさが0.12=1.2x10^-1m角として、地球の直径が12000km=1.2x10^7とすると、その空間スケールが先の時間スケールと同じ比すなわち10^8であると言及しているのだ。

 つまり、通信の速度が光速度であるとして、演算の単位クロックの間に通信が行われなければならないとするならば、計算機の時間・空間スケールと人間の時間・空間スケールは等しいだろう、という推論だ。
 
そして、さらにロゲルギストの想像は広がり、並列計算についても論じている。

 計算機が東京と大阪に離れて置かれていて、通信をしながら作業をするとしたら、人間の場合にはそれと同じ条件というのはどんなものだろうか、と彼らは考える。それは、光の速度で55時間、ちょうど冥王星の軌道直径の5倍程度の空間スケールになる、と論じている。それ以上、離れた場合には演算の過程を共に行うのは無理ではないかというのである。

 こういう文章を読んでいると、この文章が作られたのが30年以上前であることを忘れてしまいそうである。この人達の思索の自由さに憧れを感じてしまう。この人達は、頭の中にタイムマシンにでも持っているのだろうか、と感じてしまうのだ。

 ところで、私がコンピューターをいじるようになった頃は、Apple][の時代だった。といっても、私はお金があふれていたわけではないので、XXX電子でAplle][のコンパチ基盤を買って組み立てて使っていた。その基盤上の6502は1MHzで動いていた筈だ(あぁ、I/Oの6809派vs6502派の論争が懐かしい!)。

 それから20年程たち、CPUのクロックスピードは1GHzを越えようとしている。20年で1000倍である。そして、その集積度は、ムーア(GordonMoore)の法則の「半導体の性能と集積は、18ヶ月ごとに2倍になる」に従っている。

 それでは、人間はどうだろうか?人間の脳味噌のクロックがどの程度であるか測定されているかどうか、素人の私にはよくわからない。しかし、WEB上のデータとしては、例えば

というようなデータがある。ここでは、1演算/秒である。ロゲルギストの用いたものが10演算/秒である。これらは、かなり近い値と言える。もちろん、Mayoさんの演算速度はロゲルギストよりも一桁下であるわけだが、ロゲルギスト達と比べては可哀想というものだ。それに、おそらくMayoさんは謙遜しているのだと思われる。実はもう少し速いのだろう。それに比べて、私などは、二桁の演算(しかも足し算でも)になると1演算/秒もこなせるかどうか判らないくらいである。

 ロゲルギストの時代、すなわち30年以上前、から現在のMayo's Profileの値がほとんど変わっていないように、人間の演算スピードは変わるようなものではない。それは、そうだろう。ヒトのクロックスピードや集積度といったものは、変えるわけにはいかない。当然である。CPUと違ってプロセスルールを変化させるというような訳にはいかないのだ。

 それでは、演算性能を上げようとしたらどうするだろうか?そうなると、並列計算を行うのが自然だろう。単独のCPUの性能を上げるわけに行かなくても、共同作業を行えば、演算性能を上げることができる。

 現代はほとんどの作業が共同作業で行われる。また、その共同作業も大人数が関わるようになってきている。それは、どんな業種でも同じだ。一人では、なかなかできないことが多くなっている。
 それら共同作業、すなわち並列計算、を行う人達(例えれば並列計算機における各ノード)を増やし、それらの間の情報転送をすばやく行うことが多くの作業(計算)を行うための手順だろう。

 そこで、

で用いた
  • 人口増加( http://www.t3.rim.or.jp/~kabutoya/KABHTML/Yoi/2-1.html )
のデータをもう一度眺めてみることにしよう。

最近500年間の人口の変化

 なるほど、人間界の並列計算機におけるノード数は増加している。そして、各ノード間の通信速度を調べるために、まずは、

などの情報から、適当な通信の歴史を調べてみる。
西暦 内容
-4000 のろし
-2400 伝書鳩
-2300 馬による伝令制度
1837 モールス電信機
1876 ベグラハム=ベル電話機
1909 グリエルモ=マルコーン無線電話機
1973 Ethernet XeroxPARCで生まれる。(ちなみにEther=エーテル)
1979 DIX規格=10Mbps
1992 FastEthernet=100Mbps
 これを全部転送速度に直してみる。といっても、よくわからない部分も多いので、私が適当に決めてみる。それでは、その変化を示してみよう。とりあえず、ここ200年位の間のものを考える。
西暦 内容
1837 モールス電信機 = 2bps
1909 グリエルモ=マルコーン無線電話機=10kbps
1979 DIX規格=10Mbps
1992 FastEthernet=100Mbps
 という感じだ。グラフにすると、
最近200年間の情報伝送速度の変化

こんな感じである。対数グラフにおいて直線的に情報伝送速度が速くなっている。この関係は結構きれいである。
 別に意図してこういう数字にした訳ではないのだが、不思議なことである。
 このようにして、人間(ノード)間の転送レートが高くなることにより、先のような人口増加に伴うトラフィック増加をしのぐことができていると考えることもできるかもしれない。そして、人間達の共同作業、すなわち並列計算、を行うだけのバススピードを確保しているのである。

 最近、会社組織などで分社化とか事業分割とかの話題をよく耳にする。こういった時に、分割における時間と空間のスケールはよく考える必要があるだろう。分割が有効なのは、ほとんど独立なものを分割する場合のみである。並列計算における領域分割などと同じだ。

 共同作業がほとんどなく、結果のみをやりとりすれば良いような場合には分割による効果はあるだろう。その一方で、同じ事業・作業を行っているところが、離れていては作業の効率は上がらない。もし、技術系の会社でそのようなことを行うのであれば、事業や部署を並列化した際の真面目なシミュレーション位は行うべきだろう。いや、別に深い意図はないけど。

 こういったことは「新・闘わないプログラマ No.109 時代錯誤」に書かれていることとも少し似ているような気がする。

 さて、1999/12/30-2000/1/1は野沢温泉で温泉&スキーである。2000年問題で会社に泊まり込む人も多いが、私はスキー場で泊まり込みである。同時期に野沢温泉に行く人がいるならば、ぜひ一緒に「スキー場の特殊相対性理論」について討論したいと思う(スキー場で)。

2002-08-17[n年前へ]

MPIによるGIMP並列化 

 増田ら。

2004-04-29[n年前へ]

地球シミュレータの並列化率 

 試合を眺めながら、地球シミュレータを使っているチームメイトから「地球シミュレータで計算を流すための並列化率の審査」の話などを聞く。512ノード(4096台)並列化効率が50%を切らないためには、並列化率が99.98%が必要という世界には驚くばかり。遠隔ログインできないから、使うためにテクテク横浜まで訪ねて行くというのも納得か。

 MPI実装で考えたネットワーク対応版"Neko"を早く作ろう。頭が何とか動くうちに。

2006-04-29[n年前へ]

緩やかなコミニュケーションと地球シミュレータ 

 今日の「n年前へ」は「ページェントとページ」「歩いて伝わっていくこと」「地球シミュレータの並列化率」「WEBとメールの文章と本人と」などです。

人に見せるための行列をページェントなんて言いますね。ページェントとは、本などのページという言葉と関係があって、ページをめくるように見る行列のことなんです。行列が重視されるのは、たくさんの足が地面を踏んでいくことに意味があるからです。歩くとは、何もない空間を一歩一歩たどっていくことでその空間をだんだん見えるものにしていくことなんですね。

2007-12-27[n年前へ]

「ファミリーレストランで待たされないコツ」と「高速計算プログラミングのコツ」 

 雑学本を読んでいると、「ファミリーレストランでは焼き物・揚げもの・ゆで物といった種別ごとに調理担当者が決まっていて、一つの種類に注文が集中すると一度に何人分も処理できなくて、できあがりが順次遅れていくことになる。だから、ファミレスで早く同時に料理ができあがって欲しい時には、バラバラな種類をオーダーするのがコツだ」というようなことが書かれていた。

 これを読んで、思い出したのは「コンピュータで処理速度を速くしたいときのプログラミングの基本」である。たとえば、計算機の中で、処理がどのように行われるかを考えて、できるだけ効率的に並列化されるようにプログラミングをする。特定のユニットの処理が全体のボトルネックにならないように考える、といった話だ。 ファミレスの厨房の中で働く人たちに流れてくる注文や、計算機の中の色々なユニットに流れてくるさまざまなジョブを、それぞれの役割・機能に応じた処理を行っていく。 どこか一つに仕事が集中すれば、そこの速さで全ての処理速度が決まってしまう。 だから、上手く並列化・分散化するようにJOBを流すように工夫することで、早く料理を食べたり、計算結果を早く得たりする。

 しかし、振り返って考えてみれば、こういった「ファミリーレストランで待たされないコツ」と「高速計算プログラミングのコツ」といったことは、結局どんなことに対しても当てはまるのだろう。 どんなものも、どう中身が動いているかを考えて、上手く動かせば効率化できるに違いない。 もちろん、効率だけを考えるのも、それはそれで少しつまらないかもしれない。 どんなに調理に時間がかかっても、食べたいものは食べたい、と思うこともある。 人気ラーメン屋の前で、何時間も行列に並ぶ人たちがいるように。



■Powered by yagm.net