なんとなく

仕事

VMのコンパイルをしたりサウンドのテストをしたり。ことなる機械間でのファイルの移動が含まれるのだが、スニーカーネットでやるのが一番速いのだよな。そういうところに安住しがちなのが私の悪いところではあるが。

実は知らなかったのだが、SqueakのUnix用VMは最後に開いたディレクトリをopendirしたままにしておくのだった。Ianは普通はsqueak-devへのめーるにはなかなか返事をしてくれないのだが、OLPC用のVMに関してはよく面倒を見ていてくれている。

http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-October/110013.html

Strongtalkのオープンソース化

Squeak Smalltalk

むちゃくちゃ遅まきですが、StrongtalkのVMがオープンソースになったということについて。SunのJavaは、言語としては一気に人気が出たものの、とてつもなくしょぼいVMが使われていたころがありました。その時は、さまざまなSmalltalk VM作成経験のある人がSunに行って異なるJava VMを作っていた時代でもありました。今VMWareにいる(はずの)Ole AgesenもExact VMというものを作っていましたが、本命はAnimorphicという会社が買収されて(主に)そのメンバーでHotSpot VMだったわけです。AnimorphicはStrongtalkという処理系を作っていましたが、Strongtalkは今GoogleのCTOをやっているUrs HölzleがSelf VMでやっていた型フィードバックを使ったコンパイラを受け継いだものでもありました。HotSpotはStrongtalkを基にしたものの、Javaのためにほとんどのところは書き換えられたようではありますが(なので出てくるまでにそうとう余計に時間がかかっていた)、Lars Bakなどのがんばりでなんとか世に出たわけですね。(LarsはSun LabsでJohnの同僚だったわけなので、彼がMontyを作っていたころに一度紹介してもらったことがあります。興奮すると、指をぱちぱち鳴らしながらしゃべるんだよ、とJohnがうれしそうに言っていましたが)

97年ごろから始まったこういう流れにより、爆速のSmalltalk処理系だったStrongtalk VMは誰も使うことができなくなってしまい、速い処理系が世の中で使われていないことから「動的言語はどうせ遅い」というような誤解を招くことにもなっていたわけです。ただ、HotSpotそのものもオープンソースになるとか言っているこのご時世、古いコードを抱えている必要もないので、「ばあさんは用済みだから」ということでオープンソースになったのでしょう。

というわけで、David Griswoldが中心となって、StrongtalkのテクノロジーをいろいろなSmalltalk処理系、とくにオープンソースのものに注入しようという動きがあります。先日あったときには、Danもそのまま使うことにはならないということは理解したうえで、ある程度の興味を示していました。

というあたりが事実関係ですが、さて。

速くなる、というとそれだけで良いことのように聞こえますが、古めのC++で書かれた複雑なコードベースを使うのは、かなり危険だと思います。仮に5倍の速さで動くとしても、世界中で一握りの人しかメインテナンスのできないようなものは長い期間にわたって成長させていくべきオープンソース的活動にはそぐわないですからね。なにより動的言語というからには、VMのような固定化したレイヤーはなるべく小さくして、将来に渡って必要な変更をなるべく簡単に行えるようになっているほうが良いと思います。

Squeak VMの利点のひとつはSqueak自身で書かれていることで、VMのデバッグやシミュレーションをSqueak内の対話的な環境で行えることでした。そのSqueakコードをCに変換してCコンパイラでコンパイルするので、20とか30とか(数え方もいろいろありますが)のプラットフォーム上でそこそこの速度で動くようなものにできたわけです。が、欠点はやっぱりレイヤーができてしまっているということで、VMそのものの振る舞いを実行時に変えられなくなってしまっていることです(ガーベージコレクションの途中で、ある特別なことをやって欲しくなったときに、アプリケーションがそれを変えたりできないとか)。

こういう問題を解決するための方向性のひとつは、なるべく小さなVMにしようという動きがあるわけですが、ちょっとブループレーン的に考えてみると、「VMなんてものはなくしてしまって、動的言語を使って、その言語からマシンコードに変換してそれをメモリに書き込むプログラムを書けばよい」ということになります。これが最近この日記に時々出てくる「Ianのやつ」というものがやろうとしていることです。

言語からマシンコードの変換をするためには言語を定義しなくてはいけませんが、その言語の定義というのも文法とそこに書かれた変換規則というBNFチックなというかyaccチックなもので書きます。が、そもそも「yaccの記述みたいなもの」もある文法定義に従った言語ですから、自分自身で記述すればよいことになります(アイディアそのものは例によって60年代からあって、実装もされているわけですが)。

これを使うと、例えばJavaScript風の言語処理系が150行くらいの記述のみで定義できるようになります。そうしたければ、その記述内で使用されている変換規則の記述をJavaScript風の言語で行うようにすることもできます。こうやって150行くらいで書いたものが、広く使われているSafariとかのブラウザに入っている本物のJavaScript処理系より速くそして小さいメモリで動作するようになったりするわけです。もう何百行か足したりすると世界最速のJavaScript処理系になるでしょう。

その150行のほかには数千行程度で書かれた木の変換や、木のパターンからマシンコードの生成をするようなプログラムがあるわけですが、みそはそれらのコードの間には境界はないので、上から下がいつでも変更できるということです。

スピードは「最適化していないCくらい」を目指すべきでしょう。高速化を目指すためには、あらゆるところで細かな場合分けをしてそれぞれ専用のコードを書いて、フロー解析などもがんばって、ということも原理的には可能ではありますが、そうやって得られた速度と導入されてしまった複雑性とは常に天秤にかけなくてはいけません。動的言語界は遅くても許される場合が多いので、数百行という普通のプログラマでも全容が理解できる程度の記述で処理系を書いてしまって将来のユーザーの拡張を促すほうが良いのではないか、と思います。特に機械依存のところはなるべく小さいほうが良いですからね。

似たような話はLuaとかでもあるわけですが、なるべくなら「言語」ということで終わらないで、「システム」として捉えられるものを、何百万行とか何千万行とかではなく何万行かで書いて、本当に使えるものにしてみたいものです。