なぜ私たちはRuby版XOOPS Cubeを開発したか (3)


 こっからはタスクシステムの話で、なんべんか書いとる話なのでさっくりいきます。


 XOOPS Cube というか、 XOOPS の時点でモジュール開発者には色んな意識づけがなされとります。 Nuke 系のコアは CMS というより、モジュールランタイム環境なんじゃけど、そのモジュールの処理やリソースの独立制の高さ、順不同処理がモジュール開発の前提になっとるんは、今後を考えるとぶちでかい話なんよ。


 今はシングルスレッドじゃけーこんな感じよね。モジュールを追加すりゃあするだけシーケンスは縦に長ぅなって、それだけ処理に時間がかかるようになる。じゃけど、モジュールといわれとる部分は色々並列化に都合のよい前提で開発されとるけー、その前提を規約化すりゃあ、各タスクはすぐ撒ける。


 並列化のときは、理想をいやぁこんな感じにできる。モジュールを追加したぶんも、横にスケールできるようになる。あと、このスライドじゃあ、描画をモジュールの実行と同じ縦並びにしたけど、 XC のレンダリングはコマンドオブジェクトを飛ばして別のところでレンダリングするやり方じゃけえ、実際には描画も横へ並べることができる。ここまでは C/C++ で検証するところ。


 あと、 Web アプリにはマルチコア、マルチスレッドを使わんでも、非同期にするだけで処理時間を稼げそうな要素があるんよ。それが Web サービスやデータベースへのアクセス。基本 PHP は同期待ちするけぇ、 Amazon にリクエストを飛ばして戻ってくるまで1秒かかるとして、このラウンドトリップタイム中にガチで1秒待ってしまうけー、 CPU (というか VM のステップ)がぶちもったいない。
 レイテンシの間に他の CPU やハードウェアスレッド(ハイパースレッド)を働かせるのがマルチコアの基本的な速度稼ぎなら、ラウンドトリップタイムの間に CPU を働かせるのも速度稼ぎになると思うんよ。この方法は原理上 Ruby のグリーンスレッドでも検証できる。 Ruby の非同期処理ライブラリに関しては今調べよるところです。


 このダメ日記を読んどる人には、はぁ説明せんでもええと思うけど、 XC 1.0 はタスクシステムを積みます。それに将来的な並列化を見込んでおきますよ、と。


 はぁこのへんまではできとります。 XCube_PHP4 の minahito_sandbox ブランチでも覗いて遊んでみてください。


 このへんは将来の話。タスクシステムの採用と、規約作りが、スライドの最初のほうで言うとった「意識づけ」に繋がればええですね。同期とかの問題もあるけー、タスクシステムに慣れてくれりゃあ将来的にコア側で勝手にマルチスレッド化しますよ、と言い切れんところがある。


 たった1ページのまとめは……


 こがあな感じ! 今回は検証用の移植じゃったけど、ランタイムに著しい性能差がついたり、ランタイム(インストールベース)の普及数を考えると、具体的な移植の話は出てくるかもしれん。そんときは是非プロジェクトで直にやりたいですね。たとえば PHP が使えるレンタルサーバーRuby より少なくなってしまった場合は、「じゃぁ Ruby に移植するか」となるのが XC だと思います。
 とはいえ、仮に数的に PHP > Ruby じゃとしても、スライドに書いたようにランタイム環境として*1明確な性能差がついてしまった場合は、ちょっと考えにゃいけんと思います。

 ということでPDF置いときます!

*1:文法やら構文やらはどがぁでもええけど