約２ヶ月ぶりの投稿になります。実は7月末の祭りのときに親とゴタゴタがあり、その後体調を崩したりなどちょっと大変な時期でした。幸い、差し迫った仕事はなかったのでよかったのですが。
とはいえ、ただゴロゴロしていたわけではなく、いろいろ仕事に関係する勉強をしておりました。おかげで技術的な面ではやっと世界の最新動向に追いつくことができた気がします。技術的な表現バリバリのエントリですが、ご勘弁を。
Google App Engine が使えるようになりました
Ruby信者としてはPythonなんていうイケてない言語に手を出したくはなかったのですが、GAEを使いたいがために手を染めてしまいました。これで Ruby, PHP, Perl, Python の4大LL全てを一応使えることになります。まあ LLなんて機能は大概似たようなものなので、あとは自分のしたいことをWebで調べながら覚えていけばいいと思ってます。
GAEで引っかかるのはロジックの書き方よりもむしろ、NoSQL的なデータの持ち方かなぁと思います。例えばこのAPIを作るのに、最初は郵便番号・都道府県・市区町村・町名…というように小さなカラムを沢山作ってデータをアップロードしたのですが、それだと非常に時間が取られ、かつCPUタイムのリミットもすぐ上限に達してしまいます。なので、検索したいカラム(ここでは7桁の郵便番号)をキー(重複可)に、出力するJSONテキストをまるごと一つのデータカラムとして持った方が、アップロードもすんなり通りますし、ストレージ全体の使用量も少なくすみます。小さなカラムを沢山作ると各々にインデックスが作られるので、データストア領域も結構消費してしまいます。あと用語として「エンティティ」が、RDBMSで言うところの「行(またはRow)」に相当するというのは面くらいました。
最近はJRubyによるRubyコード実行も手軽にできるようになったようです。
一度慣れてしまうと、今まで個人や中小規模の企業では実現不可能だったスケーラビリティの効く実行環境を無料で始めることができ、お金がかかるとしても消費したリソースの分だけ払えばいいので、いろいろ面白いことができそうです。
Rubinius いいじゃん
Scaffold に度肝を抜かれた猿プログラマたちが大量にRailsにハマっているようですが、Rubyはいまいち性能(=速度)の面で劣っているのが実状です。Ruby自体は速くなりつつあるんですが、それにしても一度ソーススクリプトをコンパイルして、VM(YARV)上で走らせてからの話です。PHPには APCという、割合イケてる実装があって、これはバイトコードを共有メモリ上にキャッシュし、次に実行するときにはソースを読み込むのではなく、直接メモリ上のバイトコードを実行します。
Rubyでこれに近いことできないかなぁ、と思っていたら Rubinius という LLVM 上で動くRuby VM実装を見つけました。これのいいのは、実行に至るまでの各段階(Rubyインタープリタに渡すもの、構文木(S式ライク)、LLVMコード、そしてなんとアセンブリコード!)の中間コードを取り出せることで、最後のアセンブラを、できればバイナリの形で共有メモリにキャッシュすれば、かなり性能が出せるようになるのではないかと思っています。
Apacheの mpm-worker で動かせればステキなんですが、Rubinius のスレッドはMRI1.8ベースのグリーンスレッドらしく、その辺相性どうなんだろ。mpm-preforkだと24MBもあるrubinius VMはちょっとなぁ、という感じです。
OpenSkypeR(仮称)
Skypeの出始めの頃は「頭いいなぁ、こいつら」と思っていました。ダークなイメージのつきまとうファイル共有ソフト開発で培った技術をインターネット電話というクリーンなビジネスに転用していますし、P2Pなので初期インフラ投資が要らない。私が知る限りではNATの壁も難なく越えています。
ただ、難があるとすれば仕様が比較的クローズドなこと。SILKコーデックは非商用用途に限り無料かつオープンソースになりましたが、肝心のSkypeネットワークに接続する部分が非公開なんですよね。fringはその辺ハックしたんでしょうが、訴訟沙汰になっているようです。
もっとも、Skypeが世に出た当時から時代は移り、上のGAEのようにスケーラブルなインフラが比較的容易に手に入るようになってきました。となると、仕様を難解にし、開発者の人的リソースを著しく消費する複雑極まりないP2P技術(UDP Hole Punching, 分散ハッシュ, etc…)は要らなくなってきます。ハードウェアの性能が幾何級数的に向上し、性能あたりのコストもどんどん下がりつつある昨今、最もコスト視しなければならないのはソフト開発者のリソース。なら単純でオープンな仕様の方がいいですよね。
GAEのスケーラビリティとSILKコーデックの音質を生かしたオープンな仕様のオルタナティブを作れたらいいよね、という妄想のお話でした。
バイナリ or マシン語ハック
最近、布団の上に寝転がると、のび太君顔負けの速さで眠りについてしまうのですが、枕元の積ん読に「はじめての486」があります。486と言ってももう知ってる人は少ないでしょうが、私が中学生くらいのときにIntelが出したCPUで、今時のPCに載ってるCPUの5～7世代くらい前のご先祖様です。PC-9801/MS-DOS全盛だった当時、このCPUが載って、かつ価格が安いPC-AT互換機(DOS/Vは出ていなかった)の仕様を雑誌で眺めては「いいなぁ、アメリカ人は…」と溜め息をついたものでした。
時代は変わって、NECでさえ何の臆面もなくDOS/Vマシン(って今言うのか?)を出すようになりましたが、処理速度は桁違いに向上し、いくつかの命令は追加されたものの、CPUの動かし方自体は実はあまり変わっていなかったりします。古い仕様を引きずっているのは、取りも直さずソフトウェアの過去互換性のためで、要は全く違ったものを作ってしまうと今までのソフトが動かなくなるから、です。
で、今問題だと私は思っているのは、いくつかの秀逸なソフトのソースコードが手に入らず、手を加えようにも非常に苦労する羽目になることです。まあ、そういうソフトのWebページの背景色は大抵黒いんですが(笑。
であればバイナリ読解しか道はありません。元々人間の作ったものですし、暗号化さえされていなければバイナリだって読めるはず！という信念に基づいて始めています。CPUの言葉を理解できるようになれば、人間が読める形にも直せるはず、なんです・・・が、まあご想像の通り、決して易しいことではありません。
私の知人に「Fortranコンパイラの吐いたバイナリを手直しして最適化してるんだ♪」とのたまう、極めつけのスゴ腕プログラマがいらっしゃるのですが、その方の足元にやっと手が届いた感じです。何事も道は長く深く続いているものです。orz
・・・というわけで、計算機の勉強をするならシリコンバレーにも秋葉原にもいる必要はないな、と感じつつある今日この頃です。MITやUCBなら行ってもいいけど、うまい魚は食えないだろうしなぁ。
