RPC

プログラムを書く上で「関数」(或は「手続き」または「サブルーチン」)とい う仕組みを使わないことは今では考えられません。

しかし１９５０年代から１９６０年代にかけては「関数」は、今日の「オブジェ クト指向」と同じような最新の技術だったのです。何しろ当時の CPU には(１ チップではなく複数のボードで構成される)、call, ret 等の命令やスタック ポインタなどが無かったのですから。

パソコンプログラマにとって BASIC が唯一の言語だったころ(１９７０年代後 半から１９８０年代中盤)も同じで、当時の BASIC には GOTO 文はありました が GOSUB 文はありませんでした。

今のような関数という概念とは似てもにつかない、サブルーチンと呼ばれる考 え方が使われていました。何しろ jump 命令しかありませんので、サブルーチ ンに入るともう戻って来ないのです。ですから、あるサブルーチンに飛び込ん で処理が終ったら、次のサブルーチンにジャンプする、というようにプログラ ムを書くしかないのです。

トリックとして、サブルーチン毎に戻り番地を記録する変数を用意して、呼び 出す前に終ったら戻って欲しい番地を記録してからサブルーチンにジャンプす る、という方法が使われました。当然ですが、そのままでは再帰はできません。

また、スタックがありませんので、ローカル変数がとれません。

サブルーチンとは、単に処理のまとまりごとに区切って書くという事だったわ けです。

１９６０年代後半に、おそらく Algol という言語が大きなきっかけになった のだと思いますが、「手続 (Procedure)」きという考え方が導入され、CPU に も call, ret 命令やスタックが標準搭載されるようになりました。UNIX の前 身である Multics もおおよそこのころです。

コンパイラ言語は結局 CPU や OS のアーキテクチャに影響を受けてしまう。 CPU が call, ret 命令やスタックを持っていなければ「呼び出して戻って来 る」という仕組みを言語に組み込むことができません。一方、インタプリタ言 語ではそんな制約は受けません。インタプリタを作る人が凄ければナンデモア リです。

「変数への代入」というのは CPU やメモリの構造を素直に反映した概念です が、決してスマートではありません。つまり計算の進行というのは「変数の変 化」するという意味なわけです。これはフォン・ノイマン型計算機にとっては 当然の事なのですが、数学者からみるとおぞましいことです。数学の世界では 式の中の変数の値が時間(ステップ)とともに変化するというのはあり得ません。

数学の世界では「関数」というのが重要な概念です。この関数を素直にプログ ラミング言語にできないかというのを考えている一派がいました。その人達は フォン・ノイマン型計算機の制約から解き放たれた言語をつくり出しました。 それが LISP です。とは言っても結局 LISP にも変数への代入の機能が付け加 えられてしまいましたが。

C 言語を作った B.W.Kernighan がなぜ「手続き」とは呼ばずに「関数」と呼 んだのかわ分かりません。ただ、Algol や若干先行していた Pascal では、値 を返すものは function、値を返さないものは procedure と分けていました。 これは、米国の電話屋さんには面倒に見えたのでしょう。手続きは値を返さな い関数(言ってることが矛盾している)ということにすれば済むことだ、として しまいました。逆に関数を「値を返す手続き」として全てが手続きだとしてし まう事も考えられます。そうしなかったのは「社内の手続き」というのにウン ザリしていたのかもしれません。いずれにせよ C 言語ではこれが「関数だ」 という宣言するキーワードすら省かれてしまいましたので構文上はどっちでも よいことになってしまいました。

１９７０年代の計算機屋さんたちは、２０００年代に３ギガヘルツのクロック の CPU、１００メガバイトを越えるメモリ、１００ギガバイトを越えるハード ディスクを搭載したコンピュータが１０００ドル以下で買えるようになること を想像できただろうか？

何であれ、１台のものすごい速いコンピュータを作るよりは、安いコンピュー タをたくさん並べた方が、高性能/大容量の計算機を楽に実現できると考える 人は少なくなく、並列計算機の研究は１９８０年代までは盛んに行われた。並 列計算機は複数の CPU を特殊なバスでつないで作る特殊な計算機で、当然 OS も専用に開発しなければならない。今のスーパーコンピュータはこれの延長と して開発されています。このような並列計算機は開発コストがかかりすぎて商 用の製品としてはもとがとれないため、並列計算機は研究所の固有のスーパー コンピュータとして開発され続けました。

普通のコンピュータの高速化は予想以上だったので、超高速のスーパーコン ピュータを１台つくって研究所で全員で共有するよりは、研究員全員にソコソ コ速いワークステーションを提供して自分のペースで使ってもらった方が、共 有のコンピュータへのバッチ処理投入待ちの時間がなくなり、作業効率が良い と考えられるようになりました。

ワークステーションを有効に使う上で一番の問題となったのはネットワーク経 由でのファイルの転送でした。複数の人が協調して仕事をするとき、他の人が 別のワークステーションで作ったファイルを ftp で get して作業をすると、 ファイル転送のための待ち時間が生じますし、同じファイルが複数のワークス テーションに分散することになり、どれが本物(最新？)かわからなくなってし まいます。これではワークステーションにしたメリットが生きません。

そこで考えだされたのが、分散ファイルサービスです。要するにファイル共有 とかファイルサーバと呼ばれている機能です。パソコンとワークステーション の境界が無くなってしまった今ではパソコンの OS にすら標準で付いています が、当時はワークステーションだけの機能でした。

分散ファイルサービスを実現する上で、どの開発チームも通信の基盤の整備を 行いました。つまり、分散ファイルサービス用のファイル操作のプロトコルを 作るのではなく、汎用の通信基盤を作った上で、ファイル操作の機能を組み立 てるというアプローチをとりました。この汎用の通信基盤というのが遠隔手続 き呼び出し(Remote Procedure Call) です。

一方では、普通のコンピュータの高速化とネットワークの高速化によって、スー パーコンピュータの作り方が根本から変わって来ています。CPU を専用のバス で結ぶのではなく、単体でも動くコンピュータをネットワークで結んでスーパー コンピュータを組み立てるというやりかたです。グリッド型スーパーコンピュー タです。