Mono/ja

/ja

リンデンラボ･スタジオIcehouse（訳注：チーム名？）はスクリプトの動作を劇的にスピードアップするシミュレータのアップグレード評価を行っています。リンデン・スクリプト言語（LSL）自体は何も変わることがなく、故に既存のスクリプト入りオブジェクトやアタッチメントは動作が速くなるだけで、以前と変わらず動作します。この改良のキーとなるのはオープン･ソースのMonoと呼ばれる仮想マシン技術です。

計画では、今月末までMono上でのLSL動作をひきつづき評価して、その後二月をめどにベータグリッドにてMonoが動作する特定リージョンを利用可能とします。以下ではLSLとMonoがどのように協調して動作するのかを非技術者向けの文章で説明します。後に、あなたが持っているLSLスクリプトをどのようにMono用にコンパイルするか、そしてベータにはどのように参加すればよいかを説明するセクションを追加します。更新情報はこのページと公式SLブログに記載しますので注意しておいてください。

LSLスクリプトはどのように動作するか

すべてのLSLスクリプトは、あなたがいるリージョンそのものを走らせているように、シミュレータ（リンデンラボのサーバープログラム）によって動作します。テレポートしたり、リージョン境界を越えたりすると、あたらしいリージョンのサーバーがあなたが稼動させているアタッチメントのすべてのスクリプト動作を引き継ぎます。ですがシミュレータはLSLを直接理解することはできません -- スクリプト言語は人間が読みやすいように設計された書式であって機械向けのものではありません。よってスクリプトを実行できるようにためには、その前にそれらを機械が読める形に変換する必要があります。このプロセスはコンパイルと呼ばれ、その結果機械が読める形になったスクリプトのことをバイト・コードと呼びます。LSLスクリプトはレジデントのプログラマーな方がそれを作成した時点でコンパイルされます。バイト･コードそのものはリンデンラボのアセットサーバに格納され、レジデンツから直接参照されることはありえません。代わりに、あなたがスクリプト入りのオブジェクトをRezすると、いまあなたがいるシミュレータはオブジェクトの中にあるスクリプトの名前を控えて、アセット・データベースへ適切なバイト・コードを要求します。シミュレータのプログラムはいくつかの部分に分かれていますが、スクリプトのバイト･コードを実行する部分は仮想マシンと呼ばれています。

現在のセカンドライフではスクリプトはリージョンのあらゆる場所で使用されています。単純なオブジェクトを回転させるようなものから、複雑な乗り物や販売機、アタッチメントやあなたのボイス・コマンドに反応するようなものまで様々です。多くのリージョンにおいて、LSLの仮想マシンは数百ものスクリプトを一斉に稼動させようと忙しく働いています。リージョン内で稼動しているスクリプトの数の増加および複雑さ度合いの上昇によって、シミュレータに対する要求はどんどん高まっていきます。ある一定の点を越えると、仮想マシンのプロセス・タイムは他の（特に物理エンジン）シミュレータに影響し始め、結果としてサーバ側のラグを発生します。したがってスクリプトの動作をスピードアップすることができれば、そのサーバラグが起こり始める臨界点をもっと上に上げることができるわけです。

Monoの導入

Monoは（現在のものとは）別種の仮想マシンです。完全にオープンソースのもので、その高速性と汎用性は証明済です。今日に至るまで数年間においてリンデンラボはLSL仮想マシンの置き換えとしてMonoを検討してきていました。ですが仮想マシンを変更するには大きな課題があります。もっとも根本的な問題は（既存のものとMonoでは）バイト･コードが異なるという点でしょう。LSLのバイト･コードはMonoにとってチンプンカンプンのものであり、また逆もしかりです。Mono仮想マシンを使用し始める前に、私達はまずLSLスクリプトを扱うことができて、それらをMonoのバイト･コードに変換することができるコンパイラを開発する必要があります。これは非常にトリッキーです。つまりスクリプトが現在の仮想マシン上で動いているのと「まったく同じように」Mono上でも動作しているように振舞うようにしなくてはいけないわけです。これは非常に大変な仕事で、かつテストには多大な時間を要します。最終のコード作成がなされたのは2007年の第三四半期で、そしてその後 11月からリンデンラボのQA（品質保証）は新しい仮想マシンに対して一連のテストを自動および手動作業で厳しく実施してきました。

今後の計画

新しい仮想マシンへの最終のテストが行われるのはつまり住人の方々が LSLスクリプトをMonoで使用開始する段階でしょう。内部QAによるテストが終了したらまずベータグリッドで導入を開始します。ベータグリッドは現在Havok4（新しい物理エンジン）によって使用されています。ですが HetグリッドはすばらしいことにHavokと共有することができます。Hetグリッドではグリッド中のいくつかのリージョンを異なるシミュレータで動作させることができます。そこで私達はベータグリッドのいくつかのリージョンはHavokで、そしていくつかをMonoで動作させることができるのです！

メイングリッドへの導入時にもおなじHetグリッドの手法を使用します。始めはいくつかの限定されたリージョンでのみに適用し、住人の方々がMono上でもスクリプトが正しく動作するかどうか確認ができるようにします。その後しだいにMonoをグリッド全域に適用してLSLコンパイラを廃止します。

初期段階での評価

LSL2仮想マシンとMono仮想マシンを比較するベンチマークをいくつか実施しました。いくつかのテストの結果、Monoは LSL2に対して最大約220倍速いという結果を得ています。ベンチマークではパフォーマンス評価のため数値計算よりのスクリプトを使用しました。ベータプログラムが進めば住民の方々によってもっと典型的な SLスクリプトによるMonoのパフォーマンス評価が行われると考えています。

Mono How-to

Monoは現時点ではまだ一般公開していません。下記に示す手順は検討目的です。Monoのベータ開始は 2008年 1月 31日を予定日としています。

Mono下でスクリプトの評価を行いたい場合、まずMonoが稼動しているリージョンに行く必要があります。そしてMonoビュワーを使用する必要があります。詳細説明はMono beta FAQを参照してください。

• Monoビュワーをダウンロードします<まだ未提供です>。
  • このビュワーは自動的にベータ・グリッドへ接続します。
  • あなたのスクリプトをMonoでコンパイルするためのUIが実装されています。
• Monoビュワーを起動して普段と同じようにログインします。
• ベータ・グリッド内のMonoが使用可能になっているリージョンへテレポートします。
  • 大多数のリージョンはMonoではなくHavok4で稼動しています。
  • Monoリージョンは：<決まり次第お知らせします>
• スクリプトを含んでいるオブジェクトをRezします。
• オブジェクトを編集してスクリプトを開きます。
• LSLではなくMonoでコンパイルするというチェックボックスがあるのがわかるでしょう。Monoでコンパイルするためにはこれをチェックして保存を行います。
  • チェックボックスがないようであればMonoビュワーを使用していない可能性があります。
  • Monoのチェックボックスが灰色になって押せない場合、Monoが稼動しているリージョンにいない可能性があります。
• Monoという単語をオブジェクトやスクリプトの名前に付けることをお勧めします。こうすれば持ち物のなかで どのオブジェクトがMonoリージョンでのみ動作するものか見分けることができます。
• Mono下でもスクリプト入りオブジェクトが以前と同じように動作するか確認してください。
  • どんなちいさな挙動の差異も JIRAで報告してください。
  • まず、Monoメタ・イシューを見て、他の人がその件ですでに報告をしていないかどうかチェックしてください。
    • この手順は、何が問題箇所なのか？スクリプトの詳細まで追求できる場合のみ行ってください。
  • もしすでにその障害がJIRAに登録がされていた場合は、そこにあなたの発見した情報をコメントか添付で追記してください。
  • 登録がまだされていなければ発見したバグごとにSVC（サーバ関連）のチケットを切ってください。チケットのタイトルには私たちがフィルタリングできるように"Mono beta"と注記を入れるようにしてください。
  • さらに、その問題をよりよく説明するために対象のスクリプトそのもの、もしくは（理想的には）二つの仮想マシン間での挙動の違いを示すことのできる小さなスクリプトを添付してください。
  • あなたの登録したJIRA案件をメタ・イシューに関連付けてください。