携帯ゲームプログラミングHells(2)
FOMAのような高速にJavaを実行できるマシンにすると携帯の単価があがる、だから今後はbrew(C/C++)を採用する、というauの方針は正しいと思う。
それはともかく、brewとJavaについてもう少し技術的に突っ込んでみる。
brew用のアプリにキャリア側の認証が必要なのは、brew自体のセキュリティ機能が甘いからだと思われる。メモリアクセスだけの話ならばユーザーセグメント外にアクセスできないようにハード的に規制してあればそれでいいと思うのだが、悪意のあるユーザーならばAPIに対して変なパラメータを渡してバッファオーバーランのようなことは出来るだろうから、実際はそう簡単でもないのだろう。
一方Javaのほうなら、そういう心配はないのかと言えば、そうでもない。悪意のあるユーザーならば何なりと出来ると思う。まあ、そのへんの対策はベンダーにでも頭をひねっていただくとして、本当に低クロックで安価で高速なJavaマシンは不可能なのだろうか？
JavaVMのバイトコードを直接実行する安価なJavaチップが普及すれば、という話もあるが、あれはひいき目に見てもあまりいい構想だったとは思えない。*1
汎用チップでVMでJavaのバイトコードを実行した場合、10〜15倍程度の遅さであるが、JITで変換したものなら、せいぜい2〜3倍、ゲームの大半は描画等の処理時間であることを考えれば、実際の影響は2倍以下である。おまけに、Javaチップで構成した場合、何もかもをJavaコードで書かなければならない。GCさえも、である。JavaのVMコードは1命令の粒度がでかいので、すべての命令を1clockで実行できるように設計したりすると、逆にGCのような単純な処理は遅くなりかねない。かと言って、命令ごとにclock数を変えると、結局のところは汎用チップと比べてそんなに速くもならない気がする。
そう考えると、Javaチップが安価になるのを待つぐらいなら、汎用チップの進化を期待するほうがまともだ。
ところで、iモードはFOMA(900iシリーズ)でずいぶん高速化されており、Javaでも比較的まともなアプリが書けると思われている。しかし、現状でも依然商業的な開発は地獄だ。他のアプリが15FPS(frames per second)出ているなら*2、クライアント側からは、それと同じ15FPS程度は出ることを要求される。しかし、この15FPSという数字は、ゲーム中(ゲームの初期化終了後)にnewを一切呼び出さず、Cのようにプログラムを書いて、かりかりにインライン展開したりチューンしたりしてやっと到達できる数値である。それと同じスタイルのプログラムを要求されるということだ。とてもJavaのプログラムとは思えないし、こんなプログラムを書かされるぐらいならCのほうがよっぽどマシとも言える。
いつになれば、携帯Javaはこの地獄から抜け出せるのか？それは、メモリがもっとふんだんにあって、手抜きプログラムでも余裕でmax frame(60FPS?)に到達できて、チューンせずとも製品としてリリースできるようになった時である。楽観的に見てもやはり1年か2年は必要だろう。そんなわけで携帯の進化予想としては、来年はbrew全盛期になって、そのあとJavaが盛り返すような形になるのではないかと思う。
