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

計画では、今月末まで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が稼動しているリージョンに行く必要があります。そしてMonoビュワーを使用する必要があります。下記のステップ・バイ・ステップの手順に従ってください。さらにもし疑問点があればMono beta FAQを参照してください。

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

FAQ & IFAQ

質問用のセクションです。よくある質問、稀な質問のいずれも取り扱います。

Monoベータはいつ始まりますか？: Monoベータはすでに稼動しています。

Monoベータについて資料はありますか？: Mono beta FAQを参照してください。

スクリプトで使用可能なメモリは変わりますか？（現状のLSL2 VMでは16Kです）: 同じLSLスクリプトのコードを扱った場合でもMonoのバイトコードと LSL2のバイトコードは異なったサイズになります。今回私達は、すべての既存スクリプトとの互換性を保つため Monoでの上限を 64Kに拡張しました。これはMonoの場合に限ってのみできる対応です。Monoのバイトコードのアセットは動的にサイズ調整が行われます。LSL2ではどんなスクリプトでも必ず16Kを占有してしまいますが、Monoの場合は必要な容量のみ使用するからです。

Monoを使用するためには手作業で変換をしなくてはいけない？: そうです。なお Toolsメニューを使用して、選択しているスクリプトをすべてMonoでコンパイルしなおすということもできます。

自分のスクリプトを古い LSL2 VMでずっと使い続けることはできますか？: LSL2 VMを廃止する予定はいまのところありません。これについてはメイン・グリッドにMonoが導入されてしばらくしてから再検討することになるでしょう。現段階では、すべてのスクリプトを移行してもらうよりも LSL2も対応し続けておくほうがよいと判断しています。

Monoは他のいくつかの言語もサポートしていると思いますが、LSL以外の言語でもスクリプトを書けますか？: 将来的には。まずは、LSL2で LSLスクリプトを使った場合と同じになるように Monoの互換性を完璧にすることが私達の目標です。

Monoではなくて <好きな言語でどうぞ>を使わないのは何故ですか？（例：Lisp、Python、lua、javascript）: TBA（後ほど回答します）

今回、LSLに本当の開発言語のような機能は追加されますか？（例：配列、参照/ポインタ、インクルード/インポート）: いいえ。LSL言語自体は今回の更新では変更されません。

LSL2ではスクリプトはビュワー側でコンパイルされてからアップロードしていましたが、Mono VMでは変更されますか？: はい。Monoでのコンパイルはシミュレータホスト側で行われてそれを配布する方式になります。

上の質問に関連しますが、私は正規のスクリプト・テキストの形ではなく、「ちょっとしたトリック」を使ってLSL2コンパイル済みのバイトコードをアップロードしています。Monoに変更された場合、アップロード済みのスクリプトはどうなりますか？Monoスクリプトでも「ちょっとしたトリック」を使用し続けることはできますか？: Monoコンパイラはスクリプト・テキストのみを取り扱います。Mono VMは私達の Monoコンパイラでコンパイルしたバイトコードのみを実行するようになっています。Monoバイトコードをアップロードして実行することはできません。

Mono/ja

Contents