Mono/ja

/ja

"Mono for Second Life"はスクリプトの動作速度、特に演算にかかわる部分について、を劇的に向上することができる新しいシミュレータです。リンデン・スクリプト言語（LSL）自体は何も変わりません。よって既存のスクリプト入りオブジェクトやアタッチメントは動作が速くなるだけで、以前と変わらず動作します。この改良のキーとなるのはオープン･ソースのMonoと呼ばれる仮想マシン技術です。 Monoのメイングリッド導入はサーバー・バージョン1.24（8月10日導入予定です）を予定しています。これに先立ってプレビュー・グリッドで Monoのテストをすることができます（詳細は以下に記載）。

実際にMonoが稼動している状態のビデオも見ることができます。

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

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

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

Monoの導入

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

今後の計画

長らく続いていたMonoのベータ期間もようやく完了し、そろそろメイングリッドへの導入できそうです。ビュワーでの対応は7月の終わりに1.21 RCとして出される予定です。Monoサーバーは1.24として同じく7月の終わりにメイングリッドに導入予定とされています。通常ビュワーを使用しているひとも Monoスクリプトを使うことができます。単にRCビュワーを使用しない限り（Monoで）スクリプトを書くことができないというだけです。1.21が標準になれば誰もがMonoを使い Monoでコンパイルを行うことができるようになります。

Mono導入後はまずその評価について情報収集を行います。その後、段階を経てLSLバイトコードへのコンパイル機能をオフにできればと考えています。その場合でもLSLランタイムはまだ稼動できるようにしておきますので既存のスクリプトは改めてMonoに変換する必要はありません。

初期段階での評価

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

Mono How-to

Mono下でスクリプトの評価を行いたい場合、まずMonoが稼動しているリージョンに行く必要があります。そしてMonoビュワーを使用する必要があります。下記のステップ・バイ・ステップの手順に従ってください。さらにもし疑問点があればMono/Beta FAQを参照してください。

• Monoビュワーはこちらからダウンロードできます： Preview Grid 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案件をメタ・イシューに関連付けてください。

テスト

Mono実装過程ではテストを用いて逆行が生じないようにしています。最新版のレグレッション・テストは LSL Language Testを参照してください。これらは LSL仕様に沿うことを目的として提供されています。

ライブラリ・コールに関連するテストもあります。LSL Library Call Test 1 と LSL Library Call Test 2です。分割を利用することでメモリ上限の制限を回避することができます。

性能評価用のベンチマークもいくつか用意してあります。下記を参照してください：

• LSL Recursion Benchmark
• LSL Mandelbrot Benchmark
• LSL Partial Sums Benchmark
• LSL NSieve Benchmark
• LSL NSieve Bits Benchmark

FAQ

質問用のセクションです。

Monoベータはいつ始まりますか？

Monoベータはすでに稼動しています。

Monoベータについて資料はありますか？

Mono/Beta FAQを参照してください。

スクリプトで使用可能なメモリは変わりますか？（現状のLSL2 VMでは16Kです）

同じLSLスクリプトのコードを扱った場合でもMonoのバイトコードと LSL2のバイトコードは異なったサイズになります。今回私達は、すべての既存スクリプトとの互換性を保つため Monoでの上限を 64Kに拡張しました。これはMonoの場合に限ってのみできる対応です。Monoは動的にメモリ割当を行いますが、LSL2ではどんなスクリプトでも必ず16Kを占有してしまいます。Monoではスクリプトは必要な分だけのメモリを割り当てるようになっています。

64K？それって効率的じゃないスクリプトを助長することにならない？

この変更によってより効率的なスクリプト作成が行われるようになることを望んでいます。現状ではプログラマーの方々は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バイトコードをアップロードして実行することはできません。

LSLコードがすでに失われているスクリプトはどうすればよいか？例えばスクリプト自体は稼動しているが、編集をしようとすると"Script missing from database.（データーベースにスクリプトが見つかりません）"となるようなもの（訳注：何らかの原因でバイナリしか存在しないということですね）。バイトコードを変換する方法はありますか？もしくはそういったスクリプトは永遠に LSL vmでしか使えないのでしょうか？

現時点ではLSLスクリプトからのバイトコード変換の予定はありません。ソースからのコンパイルのみを認めています。レジデンツからの要求が多いようであれば対応を検討するかもしれません。

「Havok4事前評価プログラム」は非常に良い結果になったと思います。Mono事前評価プログラムは行われますか？

Mono事前評価プログラムはあまりうまく行かないと考えています。私達は漠然とですが、メイングリッドが Monoリージョンと LSL2のみサポートのリージョンで分断されてしまうのを気にしています。例えば Monoでコンパイルされたアタッチメントを付けた状態でレジデンツがリージョン間テレポートしたら、、、Mono非稼動のリージョンに飛んだ瞬間スクリプトは単純に動作を停止してしまいます。何が起きたか理解してもらえるひともいると思いますが、大半の人には何が問題かわからないでしょう。彼らはおそらくスクリプターにスクリプトを「修正」するように要求したり、LLのサポートに連絡したりしてしまうでしょう。そういったことで私達の基本戦略は、まずプレビュー・グリッドで十分にMonoのチェックをして評価を行ってから実導入、としています。

Monoがメイングリッドに導入されるのはいつ頃ですか？

現在のMonoの機能はメイングリッドに導入してすべての人に使ってもらうのに十分な品質になっていると考えています。つまりQ2です。現在の予定では7月にRCとして 1.21ビュワーにMonoビュワーの機能を統合します。サーバー側の変更はその次で、おそらくクライアントがまだRCのうちに導入されるでしょう。Monoでスクリプトをコンパイルしたい方はRCクライアントを使用すれば、Mono使用可能なシミュレータがグリッドに導入さると同時にMonoを使い始めることができます。1.21までは標準クライアントにはMono UIが実装されていませんが、事前にRCビュワーで Monoコンパイルされたスクリプトは使用することができます。

LSL2とMonoコンパイラおよび実行環境の違いはなんですか？

MonoをLSL2完全互換にしようとはしていません。少なくとも LSL2で容認されていたトリックやハックは再現しようとはしません。以下に現在判明している挙動の違いを記載します。わかり次第このリストは追記される予定です。

• ユニコードのサポート。Strife Onizukaさんからの情報「LSO LSLでは RFC 2279 （20億の文字種を扱うことができます）に準拠することでユニコード全体がサポートされていました。Monoは RFC 3629 という RFC 2279 の後継となる規格をサポートしており、これはユニコードの初めの 1,114,112文字コードをカバーしています。このことは直接的には llBase64ToString, llUnescapeURLといった関数に影響します。LSOスクリプトから Monoスクリプトへ投げられた文字列のうち、この制限域を越えるものは（定性的な動作として）化けてしまいます。」-- SVC-1960

Monoが導入された後、グリッドに存在するすべてのスクリプトをMonoでコンパイルしなおさないのは何故ですか？

一種類のコンパイラとランタイムだけをサポートするほうがより良いということはわかりますが、事前の検討によりこれは現実的ではないと判断しました。以下に私たちがそう判断した困難な点のリストを示します：

• 現在稼動しているすべてのスクリプトのテキスト（LSLコード）が保管されているわけではありません。そのような"バイトコードしかない"スクリプトは動作できなくなってしまいます。
• 自動再コンパイルをかける場合、それはつまりスクリプトをリセットすることになります。リセットすることなく継続して動作し続けることを想定して作られている多くのスクリプトがあります。
• Monoスクリプトは LSL2と比較して異なるタイミングで設計する必要があります（多くの場合 Monoのほうが速くなります）。このことで挙動の差が生じてスクリプトがわずかに破綻する可能性があります。
• いくつかのスクリプトはLSL2の非公開の機能を利用して性能向上を図っています。Monoではこのような「機能」について完全互換は目指さず、正規の想定される動作をするように勤めています。
• 以上のような理由により、スクリプトが再コンパイルされた場合、その後に品質管理の工程が必要となります。コーディングやLSLスクリプトの販売をしてる住人の方はテストの実施と、そしておそらく各スクリプトをMonoの挙動に対応させる必要があるでしょう。もし自動再コンパイルとなった場合、このような品質管理が行われる保証がありません。手動コンパイルが必要とすることで、スクリプターの方はテストや変更をしたうえでMono対応バージョンをアップグレードとして販売することができるでしょう。
• すべてのスクリプトを再コンパイルするということは権限システムからすれば高圧的とも取れるでしょう。「変更不可」で販売しているスクリプトを自動再コンパイルするということはこのポリシーに違反することになります。これをかまわないというスクリプターの方もいれば、おそらくそうして欲しくないと望む方もいるはずです。