Difference between revisions of "Mono/ja"

From Second Life Wiki
Jump to navigation Jump to search
m (help header)
(Update contens to catch up English page.)
Line 1: Line 1:
{{Help/ja|Parent=Mono|Glossary=*}}
{{Help/ja|Parent=Mono|Glossary=*}}


'''"Mono for Second Life"はスクリプトの動作速度、特に演算にかかわる部分について、を劇的に向上することができる新しいシミュレータです。'''リンデン・スクリプト言語([[LSL Portal|LSL]])自体は何も変わりません。よって既存のスクリプト入りオブジェクトやアタッチメントは動作が速くなるだけで、以前と変わらず動作します。この改良のキーとなるのはオープン・ソースの[http://www.mono-project.com/Main_Page Mono]と呼ばれる仮想マシン技術です。
{| align="right" style="text-align: center" width="375"
'''Monoのメイングリッド導入はサーバー・バージョン1.24(8月10日導入予定です)を予定しています。'''これに先立ってプレビュー・グリッドで Monoのテストをすることができます(詳細は以下に記載)。
| <videoflash>cGoM9p7q1jk</videoflash>
|-
| '''[http://vidtuts.s3.amazonaws.com/Understanding-Mono.mp4 高解像度版動画をダウンロード]''' and<br /> '''[[Mono_demos|Mono動作デモ動画いろいろ]]'''
|}


実際に'''[[Mono_demos|Monoが稼動している状態のビデオ]]'''も見ることができます。
'''"Mono for Second Life"はスクリプトの動作速度、特に演算にかかわる部分について、を劇的に向上することができる新しいシミュレータです。'''リンデン・スクリプト言語([[LSL Portal|LSL]])自体は何も変えませんでした。よって既存のスクリプト入りオブジェクトやアタッチメントは動作が速くなる可能性があるというだけで、以前と変わらず動作します。この改良のキーとなるのはオープン・ソースの[http://www.mono-project.com/Main_Page Mono]と呼ばれるスクリプト・エンジン技術です。
 
'''Monoはサーバー・バージョン1.24.3からメイングリッドに導入されました。'''




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


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


= Monoの導入 =
= Monoの導入 =
Monoは(現在のものとは)別種の仮想マシンです。完全にオープンソースのもので、その高速性と汎用性は証明済です。今日に至るまで数年間においてリンデンラボはLSL仮想マシンの置き換えとしてMonoを検討してきていました。ですが仮想マシンを変更するには大きな課題があります。もっとも根本的な問題は(既存のものとMonoでは)バイト・コードが異なるという点でしょう。LSLのバイト・コードはMonoにとってチンプンカンプンのものであり、また逆もしかりです。Mono仮想マシンを使用し始める前に、私達はまずLSLスクリプトを扱うことができて、それらをMonoのバイト・コードに変換することができるコンパイラを開発する必要があります。これは非常にトリッキーです。つまりスクリプトが現在の仮想マシン上で動いているのと「まったく同じように」Mono上でも動作しているように振舞うようにしなくてはいけないわけです。これは非常に大変な仕事で、かつテストには多大な時間を要します。最終のコード作成がなされたのは2007年の第三四半期で、そしてその後 11月からリンデンラボのQA(品質保証)は新しい仮想マシンに対して一連のテストを自動および手動作業で厳しく実施してきました。
Monoは(現在のものとは)別種のスクリプト・エンジンです。完全にオープンソースのもので、その高速性と汎用性は証明済です。今日に至るまで数年間においてリンデンラボはもともとのスクリプト・エンジン(LSL2 VMと呼ばれることもあります)の置き換えとして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でコンパイルを行うことができるようになります。
テストに協力してくれた住人の方々とQAチームのがんばりによってメイングリッドへの導入ができました。Monoサーバーは1.24から稼動開始、メイングリッドにも8月29日から導入されました。


Mono導入後はまずその評価について情報収集を行います。その後、段階を経てLSLバイトコードへのコンパイル機能をオフにできればと考えています。その場合でもLSLランタイムはまだ稼動できるようにしておきますので既存のスクリプトは改めてMonoに変換する必要はありません。
Monoは[http://secondlife.com/support/downloads.php 1.21以降のクライアント]から対応しています。ビュワーの変更点としては、スクリプト編集画面へのMonoチェックボックス追加(これをチェックすることでMonoでコンパイルすることができます。)、ツールメニューへの「選択しているオブジェクトをMonoで再コンパイル」というメニューの追加。そして、統計メニューへ従来の「単位秒あたりのインストラクション数」ではなく「単位秒あたりのイベント数」表示の追加です。Monoスクリプトを作成するためには1.21以降のクライアントが必要です。ただし、Monoスクリプトを実行するだけであれば特別なクライアントは必要ないことに注意してください。これらはすべてサーバー側で自動的に行われる処理です。Mono対応ビュワーは、単にLSL2とMonoのどちらでコンパイルをするか選択するのに必要なだけです。


その他にビュワー側で注意しておく点として統計メニュー(ctrl-shft-1)の「Script pef」があるでしょう。1.20以前のビュワーを使用した場合、この欄の表示は意味をなさないものになってしまっています。1.21以降であればこの欄は「Script events」を表示しており、1秒当たりに処理されるイベントの数をあらわしています。


= 初期段階での評価 =
メイングリッドにMonoが導入されて数ヶ月が経過したら旧タイプのスクリプト・エンジン向けにコンパイルする機能をオフにできればと考えています。その時点では新規のもの、改めて編集したものはすべてMonoで稼動しているという状況です。ただし、旧スクリプト・エンジン自体を停止するわけではありません。つまり古いスクリプトは以前と変わらず動作し続けるけれど、編集をしたりするとMonoスクリプトになるということです。
LSL2仮想マシンとMono仮想マシンを比較するベンチマークをいくつか実施しました。いくつかのテストの結果、Monoは LSL2に対して最大約220倍速いという結果を得ています。ベンチマークではパフォーマンス評価のため数値計算よりのスクリプトを使用しました。ベータプログラムが進めば住民の方々によってもっと典型的な SLスクリプトによるMonoのパフォーマンス評価が行われると考えています。
 
 
= Monoによる効果 =
旧スクリプト・エンジンMono仮想マシンを比較するベンチマークをいくつか実施しました。いくつかのテストの結果、Monoは LSL2に対して最大約220倍速いという結果を得ています。ベンチマークでは一般に性能評価用として使用するような数値計算スクリプトを使用しました。つまり普通のスクリプトでは、その効果はもっとバラついたものになるであろうということに注意してください。
 
Monoは典型的なLSL倍とコードよりも多くのメモリを消費します。そこで動的なメモリ管理を導入することで対応しています。LSL2では "Hello, Avatar"だけの単純なスクリプトでも一律に16Kを割り当てられていましたが、Monoでは必要な分だけのメモリが割り当てられます。一般的なリージョンにおけるテストでは、Monoがより多くのメモリを消費することと、よりよいメモリ管理の結果をざっくりと見てみると、全体としてのメモリ消費は良いものになるという結果を得ています。
 
極端な例ではLSL2に対して、Monoは最大4倍のメモリを消費する場合があります。そこで、後方互換性を保つためにメモリ制限は16Kから64Kに拡張しました。
 
Mono TIP:
Monoではバイトコードの共有化が行われます。同じアセットIDである限り、同一のスクリプトのコピーが複数存在していたとしても、それらは1つ分のインスタンスしか消費しません。あなたの土地で同じスクリプトがいくつも使われているような状況を想像してみてください。それぞれのオブジェクトないのスクリプトが、それぞれコンパイル処理された場合、それらはその数分だけのメモリを消費します。が、まずひとつをコンパイルして、そのコンパイル済みのスクリプトを他のオブジェクトにコピーすればいくつのコピーがあったとしても1つのスクリプト(とデータ)分のメモリしか消費しないのです。




= Mono How-to =
= Mono How-to =
サーバー1.24.3からメイングリッドでもMonoは完全対応となりました。すべてのリージョンでMonoでコンパイルしたスクリプトを稼動させることができます。Monoでコンパイルをする場合は1.21以降のクライアントが必要になりますが、コンパイル済みのMonoスクリプトを動作させるだけであれば以前の古いビュワーも使用可能です。
* Monoに対応したUI実装済みのビュワーをダウンロードします。
** 正規リリース1.21.6以降のビュワーを[http://secondlife.com/support/downloads.php ダウンロード・ページ]からダウンロードしてください。
* Monoに対応しているリージョンに行きます。
** 8月29日以降、すべてのリージョンはMono対応しています。
** 公式ブログ(英語): http://blog.secondlife.com/2008/08/20/mono-launch/
** リリースノート(英語): https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Server/1.24
** コメント用のフォーラムスレッド(英語): http://forums.secondlife.com/showthread.php?p=2115465
* オブジェクトを作成/編集してMonoでコンパイルします。
** オブジェクトを作成して新しいスクリプトを追加します。
** コンテンツタブからスクリプトの編集を行います。
** スクリプト編集画面にMonoというチェックボックスがあるのでこれをチェックします。
** 保存ボタンを押してスクリプトをMonoで再コンパイルします。
** あとは他のスクリプトと同じように扱うことができます。以降は誰が所有しているか、どのバージョンのビュワーを使っているかにかかわらず自動的にMonoランタイムで稼動します。
** チェックボックスが見当たらないようであれば使用しているビュワーがMono対応していないのかもしれません。
** Monoのチェックボックスが灰色になって押せない場合、Monoが稼動しているリージョンにいない可能性があります。
** LSL2に戻したい場合はチェックボックスからチェックをはずしてください。
* 複数のスクリプト入りオブジェクトをまとめてMonoに変換するには
** スクリプト入りのオブジェクトをすべてrezします。
** 選択ツールを使って、まとめて選択します。
** ツールメニューから「再コンパイル / Mono」を選択します。


Mono下でスクリプトの評価を行いたい場合、まずMonoが稼動しているリージョンに行く必要があります。そしてMonoビュワーを使用する必要があります。下記のステップ・バイ・ステップの手順に従ってください。さらにもし疑問点があれば[[Mono/Beta FAQ]]を参照してください。
Monoに変換したら、それらがちゃんと動作するかどうかチェックをする必要があります。Mono自体はLSL2互換ですが、動作タイミングの差異などがありますので、その影響で挙動に変化が生じる可能性があります。Monoバージョンで製品をリリースする前にチェックをするようにしましょう。


* Monoビュワーはこちらからダウンロードできます: [http://secondlife.com/community/preview.php Preview Grid viewers]
* Mono関係の事項をJIRAに報告する。
** このビュワーは自動的にプレビュー・グリッドへ接続します。
** あなたのスクリプトを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で報告してください。
** まず、[https://jira.secondlife.com/browse/SVC-1276 Monoメタ・イシュー]を見て、他の人がその件ですでに報告をしていないかどうかチェックしてください。
** まず、[https://jira.secondlife.com/browse/SVC-1276 Monoメタ・イシュー]を見て、他の人がその件ですでに報告をしていないかどうかチェックしてください。
*** この手順は、何が問題箇所なのか?スクリプトの詳細まで追求できる場合のみ行ってください。
*** 何が問題箇所なのか?スクリプトの詳細まで調べていないとこのステップは実施できないでしょう。
** もしすでにその障害がJIRAに登録がされていた場合は、そこにあなたの発見した情報をコメントか添付で追記してください。
** もしすでにその障害がJIRAに登録がされていて同じ事象のようである場合は、そこにあなたの発見した情報をコメントか添付で追記してください。
** 登録がまだされていなければ発見したバグごとにSVC(サーバ関連)のチケットを切ってください。チケットのタイトルには私たちがフィルタリングできるように"Mono beta"と注記を入れるようにしてください。
** 登録がまだされていない新しいものであれば、発見したバグごとにSVC(サーバ関連)のチケットを切ってください。チケットのサマリーに"Mono"という単語を入れておいてもらえるとフィルタリングしやすくなります。
** さらに、その問題をよりよく説明するために対象のスクリプトそのもの、もしくは(理想的には)二つの仮想マシン間での挙動の違いを示すことのできる小さなスクリプトを添付してください。
** さらに、その問題をよりよく説明するために対象のスクリプトそのもの、もしくは(理想的には)二つのスクリプト・エンジン間での挙動の違いを示すことのできる小さなスクリプトを添付してください。
** あなたの登録したJIRA案件をメタ・イシューに関連付けてください。
** あなたの登録したJIRA案件をMonoメタ・イシューにリンクしてください。




Line 73: Line 93:


質問用のセクションです。
質問用のセクションです。
; Monoベータはいつ始まりますか?
; Monoで明らかに速度が上がったというサンプルはありませんか?
: Monoベータはすでに稼動しています。
: 以下のサンプルではMonoが明らかに速度向上していることがわかります。[[LSL_Recursion_Benchmark]], [[LSL_Mandelbrot_Benchmark]], [[LSL_Partial_Sums_Benchmark]],[[LSL_NSieve_Benchmark]], [[LSL_NSieve_Bits_Benchmark]]。


; Monoベータについて資料はありますか?
; 以前LSLスクリプトを購入したのですが、何故スクリプターの人がMono対応させるまで待ったほうがよいのでしょうか?自分でやってもよくありませんか?
: [[Mono/Beta FAQ]]を参照してください。
: Monoによる速度向上の結果、複数のスクリプト間で通信を行っているような場合問題が起きることが考えられます。また、これはまれなケースですがMonoはLSLとは少し異なった動作をするようにしている場合もあります。したがってもともとのスクリプト製作者の方が変換と「テスト」をするのがより安全です。


; スクリプトで使用可能なメモリは変わりますか?(現状のLSL2 VMでは16Kです)
; Monoコンパイルされたスクリプトは旧バージョンのビュワーでも動作しますか?
: 同じLSLスクリプトのコードを扱った場合でもMonoのバイトコードと LSL2のバイトコードは異なったサイズになります。今回私達は、すべての既存スクリプトとの互換性を保つため Monoでの上限を 64Kに拡張しました。これはMonoの場合に限ってのみできる対応です。Monoは動的にメモリ割当を行いますが、LSL2ではどんなスクリプトでも必ず16Kを占有してしまいます。Monoではスクリプトは必要な分だけのメモリを割り当てるようになっています。
: はい。1.21以降のビュワーはMonoスクリプトを作成したい場合のみ必要になります。Monoはサーバー側で動作していますので、どのバージョンのビュワーを使用してもMonoスクリプトを使用することができます。
 
; Monoでコンパイルできるようになるまでどれくらいかかりますか?
: 1.21 release candidateのビュワーは 8月20日(水)にリリースされる予定です。
 
; スクリプトがMonoで動作しているかどうかを知る方法はありますか?
: いいえ。どのオブジェクトがスクリプトを含んでいて、どれがMonoで動いているかを判別するのはとても困難ですので、それを表示することは試みていません。
 
; OpenSimはMonoで動作していますが、二つの世界の間でLLによるMono実装共通化を促進するような考えはありますか?
: OpenSimの開発者の方々とMonoを基礎としたスクリプトの共通化について話し合いをすすめています。
 
; スクリプトで使用可能なメモリは変わりましたか?(現状のLSL2 VMでは16Kです)
: 同じLSLスクリプトのコードを扱った場合でもMonoのバイトコードと 旧タイプ(LSL2)のバイトコードは異なったサイズになります。今回私達は、すべての既存スクリプトとの互換性を保つため Monoでの上限を 64Kに拡張しました。これはMonoの場合に限ってのみできる対応です。Monoは動的にメモリ割当を行いますが、LSL2ではどんなスクリプトでも必ず16Kを占有してしまいます。Monoではスクリプトは必要な分だけのメモリを割り当てるようになっています。


; 64K?それって効率的じゃないスクリプトを助長することにならない?  
; 64K?それって効率的じゃないスクリプトを助長することにならない?  
: この変更によってより効率的なスクリプト作成が行われるようになることを望んでいます。現状ではプログラマーの方々は16Kの壁を越えるために複数のスクリプトを使っており、そのためにスクリプト間のデータ通信に多くのサイクルを費やしています。単体のスクリプトであればこれが必要なくなります。
: この変更によってより効率的なスクリプト作成が行われるようになることを望んでいます。現状ではプログラマーの方々は16Kの壁を越えるために複数のスクリプトを使っており、そのためにスクリプト間のデータ通信に多くのサイクルを費やしています。単体のスクリプトであればこれが必要なくなります。
; Monoを使うにあたってよりメモリ効率のよい手法はありますか?
: もちろんです。Monoはバイトコード共通化をすることができます。例えば XYTextや Puppeteerのように同じスクリプトが複数のインスタンスを使用しているようなものがリージョン内にあると考えてください。それらのインスタンスが同一のアセットIDである限り、バイトコードは1度だけしかメモリ確保されずにすべてのスクリプト間において共有化されます。この効果を確実に得られるように、スクリプトが完成したら、あとは単純にそれをコピーする(もしくはスクリプトが入っているオブジェクトをコピーする)ようにしてください。購入したスクリプトが多くのメモリを消費していたら、作成者の方にMonoバージョンについて聞いてみて、そのスクリプトをオブジェクトにコピーするようにしてみてください。ここで重要なのはアセットIDが同一になるようにコピーをするということです。もしそれぞれのインスタンスを個々に再コンパイルしてしまった場合、それらは異なったアセットIDとなるのでエンジンはバイトコード共通化を行うことができません。


; Monoを使用するためには自分のオブジェクトをすべて手作業で変換をしなくてはいけないですか?自動でやってくれるツールはありませんか?
; Monoを使用するためには自分のオブジェクトをすべて手作業で変換をしなくてはいけないですか?自動でやってくれるツールはありませんか?
: そうです。手作業でMonoへのコンパイルを実行しないといけません。なお Toolsメニューを使用して、選択しているスクリプトをすべてMonoでコンパイルしなおすということもできます。
: そうです。手作業でMonoへのコンパイルを実行しないといけません。なお Toolsメニューを使用して、選択しているスクリプトをすべてMonoでコンパイルしなおすということもできます。


; 自分のスクリプトを古い LSL2 VMでずっと使い続けることはできますか?
; 自分のスクリプトを旧スクリプト・エンジンでずっと使い続けることはできますか?
: LSL2 VMを廃止する予定はいまのところありません。これについてはメイン・グリッドにMonoが導入されてしばらくしてから再検討することになるでしょう。現段階では、すべてのスクリプトを移行してもらうよりも LSL2も対応し続けておくほうがよいと判断しています。
: 旧スクリプト・エンジンを廃止する予定はいまのところありません。これについてはメイン・グリッドにMonoが導入されてしばらくしてから再検討することになるでしょう。現段階では、すべてのスクリプトを移行してもらうよりも旧スクリプト・エンジンも対応し続けておくほうがよいと判断しています。
 
; Monoは他のいくつかの言語もサポートしていると思いますが、LSL以外の言語でもスクリプトを書けますか?
: 将来的には。まずは、LSL2で LSLスクリプトを使った場合と同じになるように Monoの互換性を完璧にすることが私達の目標です。


; Monoではなくて <好きな言語でどうぞ>を使わないのは何故ですか?(例:Lisp、Python、lua、javascript)
; Monoは他のいくつかの言語もサポートしていると思いますが、LSL以外の言語でもスクリプトを書くことはできますか?
: TBA(後ほど回答します)
: 将来的には。まずは、旧スクリプト・エンジンで LSLスクリプトを使った場合と同じになるように Monoの互換性を完璧にすることが私達の目標です。


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


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


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


; LSLコードがすでに失われているスクリプトはどうすればよいか?例えばスクリプト自体は稼動しているが、編集をしようとすると"Script missing from database.(データーベースにスクリプトが見つかりません)"となるようなもの(訳注:何らかの原因でバイナリしか存在しないということですね)。バイトコードを変換する方法はありますか?もしくはそういったスクリプトは永遠に LSL vmでしか使えないのでしょうか?
; LSLコードがすでに失われているスクリプトはどうすればよいか?例えばスクリプト自体は稼動しているが、編集をしようとすると"Script missing from database.(データーベースにスクリプトが見つかりません)"となるようなもの(訳注:何らかの原因でバイナリしか存在しないということですね)。バイトコードを変換する方法はありますか?もしくはそういったスクリプトは永遠に旧スクリプト・エンジンでしか使えないのでしょうか?
: 現時点ではLSLスクリプトからのバイトコード変換の予定はありません。ソースからのコンパイルのみを認めています。レジデンツからの要求が多いようであれば対応を検討するかもしれません。
: 現時点では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コンパイルされたスクリプトは使用することができます。


; <span id="FAQ-Differences"></span>LSL2とMonoコンパイラおよび実行環境の違いはなんですか?
; <span id="FAQ-Differences"></span>LSL2とMonoコンパイラおよび実行環境の違いはなんですか?
: MonoをLSL2完全互換にしようとはしていません。少なくとも LSL2で容認されていたトリックやハックは再現しようとはしません。以下に現在判明している挙動の違いを記載します。わかり次第このリストは追記される予定です。
: Monoを旧エンジンと完全互換にしようとはしていません。少なくとも LSL2で容認されていたトリックやハックは再現しようとはしません。以下に現在判明している挙動の違いを記載します。わかり次第このリストは追記される予定です。
:* ユニコードのサポート。Strife Onizukaさんからの情報「LSO LSLでは RFC 2279 (20億の文字種を扱うことができます)に準拠することでユニコード全体がサポートされていました。Monoは RFC 3629 という RFC 2279 の後継となる規格をサポートしており、これはユニコードの初めの 1,114,112文字コードをカバーしています。このことは直接的には [[llBase64ToString]], [[llUnescapeURL]]といった関数に影響します。LSOスクリプトから Monoスクリプトへ投げられた文字列のうち、この制限域を越えるものは(定性的な動作として)化けてしまいます。」-- {{Jira|SVC-1960}}
:* ユニコードのサポート。Strife Onizukaさんからの情報「LSO LSLでは RFC 2279 (20億の文字種を扱うことができます)に準拠することでユニコード全体がサポートされていました。Monoは RFC 3629 という RFC 2279 の後継となる規格をサポートしており、これはユニコードの初めの 1,114,112文字コードをカバーしています。このことは直接的には [[llBase64ToString]], [[llUnescapeURL]]といった関数に影響します。LSOスクリプトから Monoスクリプトへ投げられた文字列のうち、この制限域を越えるものは(定性的な動作として)化けてしまいます。」-- {{Jira|SVC-1960}}


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


; Monoはまだプレビュー・グリッドで使用することができますか?
: はい。[[Mono/Beta FAQ]]を参照してください。


[[Category:Features/ja]]
[[Category:Features/ja]]

Revision as of 19:39, 21 October 2008

<videoflash>cGoM9p7q1jk</videoflash>
高解像度版動画をダウンロード and
Mono動作デモ動画いろいろ

"Mono for Second Life"はスクリプトの動作速度、特に演算にかかわる部分について、を劇的に向上することができる新しいシミュレータです。リンデン・スクリプト言語(LSL)自体は何も変えませんでした。よって既存のスクリプト入りオブジェクトやアタッチメントは動作が速くなる可能性があるというだけで、以前と変わらず動作します。この改良のキーとなるのはオープン・ソースのMonoと呼ばれるスクリプト・エンジン技術です。

Monoはサーバー・バージョン1.24.3からメイングリッドに導入されました。


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

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

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

Monoの導入

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


今後の計画

テストに協力してくれた住人の方々とQAチームのがんばりによってメイングリッドへの導入ができました。Monoサーバーは1.24から稼動開始、メイングリッドにも8月29日から導入されました。

Monoは1.21以降のクライアントから対応しています。ビュワーの変更点としては、スクリプト編集画面へのMonoチェックボックス追加(これをチェックすることでMonoでコンパイルすることができます。)、ツールメニューへの「選択しているオブジェクトをMonoで再コンパイル」というメニューの追加。そして、統計メニューへ従来の「単位秒あたりのインストラクション数」ではなく「単位秒あたりのイベント数」表示の追加です。Monoスクリプトを作成するためには1.21以降のクライアントが必要です。ただし、Monoスクリプトを実行するだけであれば特別なクライアントは必要ないことに注意してください。これらはすべてサーバー側で自動的に行われる処理です。Mono対応ビュワーは、単にLSL2とMonoのどちらでコンパイルをするか選択するのに必要なだけです。

その他にビュワー側で注意しておく点として統計メニュー(ctrl-shft-1)の「Script pef」があるでしょう。1.20以前のビュワーを使用した場合、この欄の表示は意味をなさないものになってしまっています。1.21以降であればこの欄は「Script events」を表示しており、1秒当たりに処理されるイベントの数をあらわしています。

メイングリッドにMonoが導入されて数ヶ月が経過したら旧タイプのスクリプト・エンジン向けにコンパイルする機能をオフにできればと考えています。その時点では新規のもの、改めて編集したものはすべてMonoで稼動しているという状況です。ただし、旧スクリプト・エンジン自体を停止するわけではありません。つまり古いスクリプトは以前と変わらず動作し続けるけれど、編集をしたりするとMonoスクリプトになるということです。


Monoによる効果

旧スクリプト・エンジンMono仮想マシンを比較するベンチマークをいくつか実施しました。いくつかのテストの結果、Monoは LSL2に対して最大約220倍速いという結果を得ています。ベンチマークでは一般に性能評価用として使用するような数値計算スクリプトを使用しました。つまり普通のスクリプトでは、その効果はもっとバラついたものになるであろうということに注意してください。

Monoは典型的なLSL倍とコードよりも多くのメモリを消費します。そこで動的なメモリ管理を導入することで対応しています。LSL2では "Hello, Avatar"だけの単純なスクリプトでも一律に16Kを割り当てられていましたが、Monoでは必要な分だけのメモリが割り当てられます。一般的なリージョンにおけるテストでは、Monoがより多くのメモリを消費することと、よりよいメモリ管理の結果をざっくりと見てみると、全体としてのメモリ消費は良いものになるという結果を得ています。

極端な例ではLSL2に対して、Monoは最大4倍のメモリを消費する場合があります。そこで、後方互換性を保つためにメモリ制限は16Kから64Kに拡張しました。

Mono TIP: Monoではバイトコードの共有化が行われます。同じアセットIDである限り、同一のスクリプトのコピーが複数存在していたとしても、それらは1つ分のインスタンスしか消費しません。あなたの土地で同じスクリプトがいくつも使われているような状況を想像してみてください。それぞれのオブジェクトないのスクリプトが、それぞれコンパイル処理された場合、それらはその数分だけのメモリを消費します。が、まずひとつをコンパイルして、そのコンパイル済みのスクリプトを他のオブジェクトにコピーすればいくつのコピーがあったとしても1つのスクリプト(とデータ)分のメモリしか消費しないのです。


Mono How-to

サーバー1.24.3からメイングリッドでもMonoは完全対応となりました。すべてのリージョンでMonoでコンパイルしたスクリプトを稼動させることができます。Monoでコンパイルをする場合は1.21以降のクライアントが必要になりますが、コンパイル済みのMonoスクリプトを動作させるだけであれば以前の古いビュワーも使用可能です。

  • Monoに対応したUI実装済みのビュワーをダウンロードします。
  • Monoに対応しているリージョンに行きます。
  • オブジェクトを作成/編集してMonoでコンパイルします。
    • オブジェクトを作成して新しいスクリプトを追加します。
    • コンテンツタブからスクリプトの編集を行います。
    • スクリプト編集画面にMonoというチェックボックスがあるのでこれをチェックします。
    • 保存ボタンを押してスクリプトをMonoで再コンパイルします。
    • あとは他のスクリプトと同じように扱うことができます。以降は誰が所有しているか、どのバージョンのビュワーを使っているかにかかわらず自動的にMonoランタイムで稼動します。
    • チェックボックスが見当たらないようであれば使用しているビュワーがMono対応していないのかもしれません。
    • Monoのチェックボックスが灰色になって押せない場合、Monoが稼動しているリージョンにいない可能性があります。
    • LSL2に戻したい場合はチェックボックスからチェックをはずしてください。
  • 複数のスクリプト入りオブジェクトをまとめてMonoに変換するには
    • スクリプト入りのオブジェクトをすべてrezします。
    • 選択ツールを使って、まとめて選択します。
    • ツールメニューから「再コンパイル / Mono」を選択します。

Monoに変換したら、それらがちゃんと動作するかどうかチェックをする必要があります。Mono自体はLSL2互換ですが、動作タイミングの差異などがありますので、その影響で挙動に変化が生じる可能性があります。Monoバージョンで製品をリリースする前にチェックをするようにしましょう。

  • Mono関係の事項をJIRAに報告する。
    • まず、Monoメタ・イシューを見て、他の人がその件ですでに報告をしていないかどうかチェックしてください。
      • 何が問題箇所なのか?スクリプトの詳細まで調べていないとこのステップは実施できないでしょう。
    • もしすでにその障害がJIRAに登録がされていて同じ事象のようである場合は、そこにあなたの発見した情報をコメントか添付で追記してください。
    • 登録がまだされていない新しいものであれば、発見したバグごとにSVC(サーバ関連)のチケットを切ってください。チケットのサマリーに"Mono"という単語を入れておいてもらえるとフィルタリングしやすくなります。
    • さらに、その問題をよりよく説明するために対象のスクリプトそのもの、もしくは(理想的には)二つのスクリプト・エンジン間での挙動の違いを示すことのできる小さなスクリプトを添付してください。
    • あなたの登録したJIRA案件をMonoメタ・イシューにリンクしてください。


テスト

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

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

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


FAQ

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

Monoで明らかに速度が上がったというサンプルはありませんか?
以下のサンプルではMonoが明らかに速度向上していることがわかります。LSL_Recursion_Benchmark, LSL_Mandelbrot_Benchmark, LSL_Partial_Sums_Benchmark,LSL_NSieve_Benchmark, LSL_NSieve_Bits_Benchmark
以前LSLスクリプトを購入したのですが、何故スクリプターの人がMono対応させるまで待ったほうがよいのでしょうか?自分でやってもよくありませんか?
Monoによる速度向上の結果、複数のスクリプト間で通信を行っているような場合問題が起きることが考えられます。また、これはまれなケースですがMonoはLSLとは少し異なった動作をするようにしている場合もあります。したがってもともとのスクリプト製作者の方が変換と「テスト」をするのがより安全です。
Monoコンパイルされたスクリプトは旧バージョンのビュワーでも動作しますか?
はい。1.21以降のビュワーはMonoスクリプトを作成したい場合のみ必要になります。Monoはサーバー側で動作していますので、どのバージョンのビュワーを使用してもMonoスクリプトを使用することができます。
Monoでコンパイルできるようになるまでどれくらいかかりますか?
1.21 release candidateのビュワーは 8月20日(水)にリリースされる予定です。
スクリプトがMonoで動作しているかどうかを知る方法はありますか?
いいえ。どのオブジェクトがスクリプトを含んでいて、どれがMonoで動いているかを判別するのはとても困難ですので、それを表示することは試みていません。
OpenSimはMonoで動作していますが、二つの世界の間でLLによるMono実装共通化を促進するような考えはありますか?
OpenSimの開発者の方々とMonoを基礎としたスクリプトの共通化について話し合いをすすめています。
スクリプトで使用可能なメモリは変わりましたか?(現状のLSL2 VMでは16Kです)
同じLSLスクリプトのコードを扱った場合でもMonoのバイトコードと 旧タイプ(LSL2)のバイトコードは異なったサイズになります。今回私達は、すべての既存スクリプトとの互換性を保つため Monoでの上限を 64Kに拡張しました。これはMonoの場合に限ってのみできる対応です。Monoは動的にメモリ割当を行いますが、LSL2ではどんなスクリプトでも必ず16Kを占有してしまいます。Monoではスクリプトは必要な分だけのメモリを割り当てるようになっています。
64K?それって効率的じゃないスクリプトを助長することにならない?
この変更によってより効率的なスクリプト作成が行われるようになることを望んでいます。現状ではプログラマーの方々は16Kの壁を越えるために複数のスクリプトを使っており、そのためにスクリプト間のデータ通信に多くのサイクルを費やしています。単体のスクリプトであればこれが必要なくなります。
Monoを使うにあたってよりメモリ効率のよい手法はありますか?
もちろんです。Monoはバイトコード共通化をすることができます。例えば XYTextや Puppeteerのように同じスクリプトが複数のインスタンスを使用しているようなものがリージョン内にあると考えてください。それらのインスタンスが同一のアセットIDである限り、バイトコードは1度だけしかメモリ確保されずにすべてのスクリプト間において共有化されます。この効果を確実に得られるように、スクリプトが完成したら、あとは単純にそれをコピーする(もしくはスクリプトが入っているオブジェクトをコピーする)ようにしてください。購入したスクリプトが多くのメモリを消費していたら、作成者の方にMonoバージョンについて聞いてみて、そのスクリプトをオブジェクトにコピーするようにしてみてください。ここで重要なのはアセットIDが同一になるようにコピーをするということです。もしそれぞれのインスタンスを個々に再コンパイルしてしまった場合、それらは異なったアセットIDとなるのでエンジンはバイトコード共通化を行うことができません。
Monoを使用するためには自分のオブジェクトをすべて手作業で変換をしなくてはいけないですか?自動でやってくれるツールはありませんか?
そうです。手作業でMonoへのコンパイルを実行しないといけません。なお Toolsメニューを使用して、選択しているスクリプトをすべてMonoでコンパイルしなおすということもできます。
自分のスクリプトを旧スクリプト・エンジンでずっと使い続けることはできますか?
旧スクリプト・エンジンを廃止する予定はいまのところありません。これについてはメイン・グリッドにMonoが導入されてしばらくしてから再検討することになるでしょう。現段階では、すべてのスクリプトを移行してもらうよりも旧スクリプト・エンジンも対応し続けておくほうがよいと判断しています。
Monoは他のいくつかの言語もサポートしていると思いますが、LSL以外の言語でもスクリプトを書くことはできますか?
将来的には。まずは、旧スクリプト・エンジンで LSLスクリプトを使った場合と同じになるように Monoの互換性を完璧にすることが私達の目標です。
今回、LSLに本当の開発言語のような機能は追加されますか?(例:配列、参照/ポインタ、インクルード/インポート)
いいえ。LSL言語自体は今回の更新では変更されません。
旧スクリプト・エンジンではスクリプトはビュワー側でコンパイルされてからアップロードしていましたが、Monoでは変更されますか?
はい。Monoでのコンパイルはシミュレータホスト側で行われて それを配布する方式になります。
上の質問に関連しますが、私は正規のスクリプト・テキストの形ではなく、「ちょっとしたトリック」を使ってLSL2コンパイル済みのバイトコードをアップロードしています。Monoに変更された場合、アップロード済みのスクリプトはどうなりますか?Monoスクリプトでも「ちょっとしたトリック」を使用し続けることはできますか?
Monoコンパイラはスクリプト・テキストのみを取り扱います。Monoエンジンは私達の Monoコンパイラでコンパイルしたバイトコードのみを実行するようになっています。Monoバイトコードをアップロードして実行することはできません。
LSLコードがすでに失われているスクリプトはどうすればよいか?例えばスクリプト自体は稼動しているが、編集をしようとすると"Script missing from database.(データーベースにスクリプトが見つかりません)"となるようなもの(訳注:何らかの原因でバイナリしか存在しないということですね)。バイトコードを変換する方法はありますか?もしくはそういったスクリプトは永遠に旧スクリプト・エンジンでしか使えないのでしょうか?
現時点ではLSLスクリプトからのバイトコード変換の予定はありません。ソースからのコンパイルのみを認めています。レジデンツからの要求が多いようであれば対応を検討するかもしれません。
LSL2とMonoコンパイラおよび実行環境の違いはなんですか?
Monoを旧エンジンと完全互換にしようとはしていません。少なくとも 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スクリプトは以前と比較して異なるタイミングで設計する必要があります(多くの場合 Monoのほうが速くなります)。このことで挙動の差が生じてスクリプトがわずかに破綻する可能性があります。
  • いくつかのスクリプトはLSL2の非公開の機能を利用して性能向上を図っています。Monoではこのような「機能」について完全互換は目指さず、正規の想定される動作をするように勤めています。
  • 以上のような理由により、スクリプトが再コンパイルされた場合、その後に品質管理の工程が必要となります。コーディングやLSLスクリプトの販売をしてる住人の方はテストの実施と、そしておそらく各スクリプトをMonoの挙動に対応させる必要があるでしょう。もし自動再コンパイルとなった場合、このような品質管理が行われる保証がありません。手動コンパイルが必要とすることで、スクリプターの方はテストや変更をしたうえでMono対応バージョンをアップグレードとして販売することができるでしょう。
  • すべてのスクリプトを再コンパイルするということは権限システムからすれば高圧的とも取れるでしょう。「変更不可」で販売しているスクリプトを自動再コンパイルするということはこのポリシーに違反することになります。これをかまわないというスクリプターの方もいれば、おそらくそうして欲しくないと望む方もいるはずです。
Monoはまだプレビュー・グリッドで使用することができますか?
はい。Mono/Beta FAQを参照してください。