05年9月 diary

最新の日記へ  前の月へ  次の月へ  日記INDEX  HOME

9月28日 

マイクロプロセッサは一つのコア当たりの性能を高めるよりもコア数を増やして同時実行できるスレッド数を増やす事によって性能向上をするのが今後のトレンドである

参考: Concurrency (radium software)

したがって、並列性を使ってソフトウェア性能を高めるにはどうしたら良いかが問題になってくる。 多くの論考では並列処理の話題になると、とたんに並列性の抽出の難しさや、排他制御の困難性の話題になって、「大変だね」という結論になってしまう。

しかし、それは問題の捉え方を間違っている。今日びの大抵のプログラムはわずかな工夫で抽出が容易で排他制御の必要ない巨大な並列性を持っている。それは主に二つある。

まず一つはループの並列性である。大抵の時間のかかるプログラムは深くネストしたネストしたループ構造を持っている。適当に言ってもいいのなら、main()関数から数えると7、8重くらいあるだろう。そのうち幾つかは、実際には評価順序に依存しないようなループである。つまりループのインデックスを昇順で処理しようがランダムに処理しようが結果が変わらないようなループである。

このようなループはそのまま並列処理をする事ができる。 このようなループも何重にも重なっていることはしばしばあるので、そのループ数の積がそのまま並列性になる。

この種の並列性の抽出は容易である。
hoge* B = malloc(sizeof(hoge)*n);
for(int i=0; i< n; i++){
 B[i] = enormous_calculation(A[i]);
}
古い時代の言語はこんな感じで並列性を持った内容でも最大限に直列的に書くように出来ている。それが間違いなのだ。
 B = map(enourmous_calculation, A);
のように並列な内容を最大限並列に書くような言語があれば容易に並列性を抽出する事ができる。

これは言語が配列をサポートして、それに対してmap関数などをもち、そのmap関数は評価順序を保証しない事、map関数から呼び出される関数は副作用を持ってはいけないことを言語として明記すれば充分である。C言語でさえちょっとしたプラグマを導入すれば済む程度の話しだ。 そして、このような並列なループは実際には何重に重なっていることが多いのでかなりの並列性が稼げる。

このような書き方をするにあたっては関数に副作用があるかないかを常に意識する必要があるが、それもどうと言う事もない。いまでもほとんどのプログラマは日常的に副作用があるかどうかを意識している。副作用のない関数は安全であり、それが可能な限りはそれが望ましいからだ。

第二に、どんな言語でも見られるようなごく普通の計算式
y = a*b + c*d;
のような物でも並列性を持っている。a*bとc*d同時に評価可能だ。これではあまり有り難く感じないかも知れないが、
y = big_fn(a) * anothor_big_fn(b);
とかであれば、関数の評価が同時に進めばそのまま2倍の並列性を稼ぐ事ができる。

ここで必要なのはやはりbig_fn()などが副作用を持たない事だ。副作用が無ければ排他制御は一切不要だからである。

結局まとめると関数型プログラミングが通用する部分になるわけだ。

さて、これらの並列性を全て並べると、ごく普通のプログラムでもあたりまえに数百から数千に達する並列性を持っている。これを実際に利用するためにプログラマがわに必要なのは、できるところでは副作用のないプログラミングすることだけだ。

この並列性を最大限に活かすマイクロプロセッサのアーキテクチャは、構文木を直接実行するようなプロセッサである。 現在のレジスタと命令からなるアーキテクチャは、計算の結果が何に使われるのか分からずに、構文木の末端に当たる部分から計算をするいわば「プッシュ型」のアーキテクチャである。 一方、構文木の実行は欲しい結果からそれに必要な枝葉末節までが木として記述された、「プル型」である。後者の方は最終結果を得るのに必要な演算が最大限に並列に記述された形式であるゆえに、ある限りの並列資源にあわせて最大に計算をする事ができるが、前者は必要な計算が最大限に直列に書かれているゆえに、並列性の抽出には大きな困難がともなう。

しかし、そのために新規のアーキテクチャを設計するのは得策では無い。 新技術は原理的に優れていても、旧来の技術の方には遥かに巨額の開発投資がなされているために、旧来の技術に追いつけないことがよくある。 また、すぐには分からない欠点があることもある。 まずするべきは漸進して様子を見る事である。

したがって、今は、このような並列実行を可能とする二またコール命令を既存CPUに加える事で充分だろう。その二またに達したら、もう一つのCPUがあいていればそれにコールの一方を実行させるような命令である。

いやちょっと長くなりすぎた。もっと簡単に書けるな。

1、関数型プログラミングは、たまたま並列性を最大に記述する方法でもある。それを利用すれば並列性の抽出は容易だ。

2、関数型のプログラムの構文木を直接実行するプロセッサがあるといい。でもそこまで行かなくとも二股同時実行コール命令を追加するだけでも効果がある。


10月2日追記:これについてShiroさんがもう一歩踏み込んだ議論をしています。

9月23日 

少なからぬ研究者が脳の中ではダイナミクスの結果としての要素間の自発的なsynchronization(同期)が情報の処理に重要な役割を果たしていると考えている。

一方、コンピュータやその他の電子機器、情報機器の中ではsynchronizationはクロックに対する一方的な同期によって実現されている。

この差が、脳の情報処理能力のコンピュータとの違いと関係あるという意見もしばしば見られる。 (その前に実験的証拠は少ないことは注意しておく。) しかし私はそうは思わない。

人間が作った機械が自発的で、相互的な、ダイナミカルな同期をあまり使わないのは、それができないからではない。非線形関数と微分方程式ならそのまま電子回路的に実現できるのだから、あの種の研究で提案されているようなダイナミクスなら何でも実現可能である。

それを機械が使わない理由は、単にそれが不確かで、信頼できなく、結果が不安定であるからに過ぎない。また反対に強制的で、一方的で、メカニカルな同期機構を人工機械が多用する理由はそれが信頼できて結果が安定しているからである。

これらの得失点は神経細胞を使った情報処理機構の実装(=脳)でも同じでは無いだろうか?それとも何か違うと考えるべき理由があるのだろうか?

9月22日 

ふと不思議に思ったのだが、なぜ人体はまばたきを両目で同時にするように出来ているのだろうか。別々にすれば何も見えなくなる時間をゼロにすることができるのに。つまらんことだけど不思議だ。

差別利権集団にとっては差別は「なくては困る」ものである。 連中にとってもっとも望ましいのは差別は大して無いけど、「差別がある」という主張は精査されることなくまかり通るような状況である。

ポエム:

過去は実在ではない。
現在の観測をもとに推定されたのが過去である。
過去について観測によって知りうる事には限界がある。
この限界が非可逆な情報の損失のようにに見える。

9月13日 

Matlabでrgb2ntscを使っているプログラムにぶちあたった。 それだけの為に何十万円もするimage toolboxを買うのもアホらしいので自分で作ることにした。(アメリカではライセンスは安いらしいぞ。)

MatlabでNTSCカラー空間と呼んでいるのは一般にはYIQ色空間と呼ばれているもののようだ。
http://www.cybernet.co.jp/matlab/support/helpdesk/r14/toolbox/images/color11.shtml

function Y = rgb2ntsc(X) 
% poorman's rgb2ntsc converts RGB to YIQ
Y = X;
r = X(:,:,1); 
g = X(:,:,2); 
b = X(:,:,3); 
Y(:,:,1) = 0.2990*r + 0.5870*g + 0.1140*b
Y(:,:,2) = 0.5959*r - 0.2750*g - 0.3210*b
Y(:,:,3) = 0.2065*r - 0.4969*g + 0.2904*b

function Y = ntsc2rgb(X)
% poorman's ntsc2rgb converts YIQ to RGB
Y=X;	
y = X(:,:,1); 
i = X(:,:,2); 
q = X(:,:,3); 
Y(:,:,1) = y + 0.9489*i + 0.6561*q
Y(:,:,2) = y - 0.2645*i - 0.6847*q
Y(:,:,3) = y - 1.1270*i + 1.8050*q
Matlabでは色は第三インデックス。

変換式は 「 色のお話」を参考にした。

9月8日 

海馬の機能についての私見

海馬の機能は、不可分な個体(そして個物と場所)に対応した符号の形成である

現在の所、私は海馬の機能をそう考えている。

一つの個体や個物は複数の感覚的特徴からなっている。 感覚的特徴とは中程度に複雑な図形的特徴やら、それと色の組み合わせやら、ある種の音とかそういうもの。モダリティは視覚に限らず、聴覚、触覚なんでもある。 で、それらの組み合わせによって、いま目の前にいるものは何なのか我々は認識している。

感覚的特徴は部分的な特徴なので全く違ったものの間でも共通のものもある。 このような共通の部分に惑わされずに個物を識別するのが、まず第一。

不可分な個体を識別する計算論の原理は簡単にいえば、いつも例外なく一緒にあらわれる特徴は不可分なものの一部であり、一緒にあらわれない事がある特徴は別の不可分のものの一部である、ということである。 しかし、一緒にあらわれるからといって不可分であるとは限らないし、不可分のものの一部が隠されたりして一緒にあらわれない事もあるという問題がある。 これについては進化的になにか適当なしきい値が設定されているのだろう。またモダリティによっても、扱いが違うだろう。例えば触覚については触っていなければ無しなのだから他のモダリティと違う補正がなされているだろう。

さて、海馬の各部分にこのために必要な機能を割り振ってみる。

海馬の最初に信号が入る歯状回は、必ず一緒にあらわれる複数の特徴を表す符号を一つにまとめる。うまく行けば個物を表す符号にまで辿り着く。

次のCA3野では、歯状回の出力を受けて、一つの物体に属する特徴でも、たまたま隠されて見えなかったり、その他のノイズ要因によって欠けた部分を再帰的連想記憶の仕組みによって復元する。

(ここで、歯状回およびCA3野の出力について特徴の圧縮された符号と個物の符号の中間のように考えている。もう少しどちらなのか考えをはっきりさせた方が良いかもしれない。)

CA1では個物の表現を、連想記憶の仕組みによって、もとの特徴の集まりに戻す。

(しかしこれが正しいとすると、空間の位置のidentificationと物体のidentificationは混同されてはならないから歯状回やCA3では両者の情報がconvergeしてはいけないはず。しかしWitterらはむしろそこにおいてのみconvergenceがあることを見つけている。 どう考えるべきだろうか。いつも同じ場所にある物体は空間上の位置の手がかりになると考えれば矛盾ではなくなるのだろうか?)

9月3日 

基底核の機能についての私的仮説

大脳基底核はいくつもの部分からなっているが、その働きは行動の候補を列挙しそのどれを実行するか決定する事である。

この場合「行動」には、例えば手を伸ばすのような即物的な動作もあるが、たとえば「どこに注意を向けるか」とか、何を考えるのかなどの内部的な物もある。 つまり認識、注意、思考なども行動と同じ仕組みによって決定さる行動の一種と言える。

どの行動をするかの決定は、過去の経験をデータとして、確率論を使って報酬の期待値を最大化する行動を選択する事によって決定する。

9月2日 

作者が死んでも生き残る言語とは

現在、プログラミング言語はカンブリア爆発のような爆発期にある。感じでは世界に個人的に作られた言語は1万くらいあるんじゃないかと思う。

このような爆発の背景は有り余るCPUパワーがあり、それをプログラミングの容易性に使うにはどうしたら良いかという試行錯誤がおこわなられていると考える事ができる。

さて、当然ながらこれらの言語のほとんどは生き残らないだろう。大部分は単に出来が悪いとか運が悪いという理由から消えていくだろう。 しかし、それを突破しても作者が死ねば、多くの言語は消えてしまうだろう。 言語は新しいCPUやOSなどの環境に対応するためや新しいライブラリを加えるためにメンテナンスされ続ける必要があるし、それがされなくなれば消える運命だ。 作者が死んでもメンテナンスされ続けるためには他の人がメンテナンスを続ける必要がある。

しかし、他の人がその言語の言語らしさを失わずにメンテナンスし続けるためにはその言語の本質が他の人にも作者と同じように把握できなければならない。 それが何を意味するか、実際に昔に作られた言語でありかつ作者が死んでも生存しそうな言語を考えてみよう。私が知る範囲でいかにもずっと生き残りそうなのはCとLISPだ。(LISPはマイナーかも知れないけど滅ぶ事はないだろう。)

私が考えるに、こららの言語の特徴とは中核となるモデルの単純さだ。C言語は要するに「レジスタマシンのマシンコードに最低限の抽象化をして高級言語っぽく見せる」というのがモデルだ。(特にレジスタとスタックをまとめて「自動変数」という抽象化を行ったのがもっとも重要なところだと思う。アセンブラからくらべて。)LISPの中核モデルはラムダ計算だ。

このような極めて単純でゆえに恣意性の余地のないモデルが中核にあって初めて言語の本質は他の人にも把握可能になるのだろう。 そして、そのような単純な中核のモデルがない言語はいずれ滅ぶものと思う。例え作者が死ななくてさえ。


| Home |
T. Mogami
e-mail: mogami@yugiri.bnf.brain.riken.go.jp