またまた恐縮ですが、ビュワーのお話しです。＾＾；；
ベーターグリッド用のビュワーが新しくなり、以前からリンデンがアナウンスしてるMONOグリッドに対応したリリース版がでました。
これはなんなのか？についてですが、現在ＳＬはほぼ1.21.1グリッドに移行していますが、そもそもグリッドというＳＩＭ（シュミレーション）は３Ｄのレンダリングのために存在しています。
でもＳＬでは実際、自動車に乗ったり、飛行機に乗ったり、ダンスをしたりと様々なことが可能になって、それがイン・ワールドを魅力的にしているわけですが、その恩恵はLSL、つまりリンデンスクリプトによって実現しています。
よくサーバーが再起動することがあり、警告がでてＳＩＭをでなければいけない事があるでしょう？
これには様々な原因がありますが、最も多いのが至るところで高速にＬＳＬを処理しようとするため、どうしてもサーバー側の処理が非常に負荷のかかった状態になるため、リセットしなくてはならないから・・・というのが多いのです。よく”ラグ”という表現がされます。
そもそもＬＳＬはＳＩＭがサポートしているのではなくて、ＬＳＬを実行できる環境をＳＩＭ側のオブジェクトが呼び出して実行するという仕組みです。ＳＩＭ自体はスクリプト実行環境ではないということ。こういうのをＪＡＶＡではよくＶＭ（バーチャルマシン）という呼び名を使います。そもそも実行環境ではないが、それを動作させる状態をサーバー同士で連携して持ってくるというわけ。
まあ、自宅で野球は無理だが、空中に球場作ってそこで試合やろうと、どっかから環境を持ってくるという感じでしょうか。
で、現在ＬＳＬはＬＳＬ２というバージョンらしんですが、これが動作で得きる環境は今の状況ではかなりキビシイといわざるを得ないようです。サーバー側が対応しきれず、結局”ラグ”の上限にすぐ達してしまう。よくあるのがキャパシティーがもの凄いダンスクラブでＳＩＭごと落ちる・・といった場合がそうです。限界点が低いというわけ。 それに至るところでＨＵＤだらけの人たちがダンスしてますからね。正確にはＳＩＭが落ちるというより、ＬＳＬ環境との連携が処理が追いつかず拒否された状態。すると完全にフリーズしたようになり、サーバー側で再起動して環境をリセットしないといけない状態になるということ。
サーバーが「もうデキネーよ！！」とキレた状態です＾＾；
そこでリンデンではこれを解消しようとして、以前から別のＶＭを検証して実験を重ねてきたそうで、これは非常にＬＳＬを高速で処理できる事が実証出来たそうです。
公式ブログにあるビデオは何をやっているかというと、このMONO VMが働くＳＩＭで（適用されたサンドボックスが既に稼働しています）サーバーに負荷のかかるベンチマーク用スクリプトを動作させてる様子です。もの凄い数のプリムが生成されていますよね。ちょうどアバターを真上から俯瞰で見た視点で撮影しています。
http://blog.secondlife.com/2008/05/15/mono-beta-refresh-9/
将来的にはこのMONO VMが動作する環境を全てのＳＩＭで実現するのが、リンデンの目標のようです。しかし、公式ＷＩＫＩでは「その道のりは長い」としています。なんでもＬＳＬ２とMONO VMではバイトコードといって、平たくいえばプログラムの解釈が違うのです。
JAVAなどがそうですが例えばウィンドウズ用のソフトをMACで使おうと思っても動くわけがないのは誰でもわかりますよね？それはそもそも、プログラムが書かれているコードがお互い違うからで、もっといえばプログラム言語はそれが動作できる環境が同じでないと普通動作しません。
それじゃ不便なんで、もとになるプログラムは別のトコロに置いておいて、インストール先のプログラムによって環境を読み込んで動作させようという考えが出来ました。バイトコードとはそのＶＭとＬＳＬの仲を取り持つ中間管理職みたいなもの。ところが、ＭＯＮＯと現在のLSL2では、担当がそれぞれ違うので、仲良くやるために、ちと考えてやらないといけないということになる・・。
まあプログラム言語を1から作り直すのと同じですね。
この仕組みによって、従いソフトは「プログラム本体は別のトコロから頂戴する」様な感じになり、ソースコードはカンタンになるは、ＯＳ違っても動作するわで万々歳・・と行きたいところですが、チトこれには越えなきゃならないハードルがあるわけです。
それは肝心の動作環境を与える側、ＶＭの方です。何せ数万のアバターが一斉にＬＳＬを知らず知らず実行している状態が今のＳＬ。当然常にサーバーは忙しくＬＳＬを実行して環境を呼び出し処理を実行しなければいけない・・。今のＳＬは非常にＬＳＬをこのまま実行し続けるのは、もう限界に来ている・・。
そこで、このビュワーをＭＯＮＯ ＶＭのテストに住人にテストしてもらいたいというわけ。ついでにバグ出しも・・。
ＬＳＬというのは、「スクリプトを新しく作成」で保存すれば、デバックとコンパイル（難しい言葉で言えばバイトコードに変換する）を同時に実行するので、普通に使えますが、ＭＯＮＯ ＶＭが動作している環境でこれをやると、havok4や現在のグリッドでは動作しません。バイトコードに変換したトコロと同じ環境でないと実行できないというのが今の現状。
こう聞くと、やはりＳＬはビュワーを使う側のスペックの問題よりも、ＬＳＬの処理をどうするかがほとんどパフォーマンスに関わっているというのがわかります。
まあレンダリングによってクソ重くなるのは別ですが。
ＭＯNO VMについての文献はどれも英語なのですが、バーチャル・マシンとはなにか？については、ＮＥＣで文献を公開しています。ただし難しいデスヨ。＾＾
http://www.nec.co.jp/techrep/ja/journal/g05/n02/t050211.pdf
ヴァーチャルマシンとはなんじゃいな？
ＶＭの技術は数が多くて、主にＪＡＶＡ開発のSun microsystemsとマイクロソフトやVM Wareなど,覇権をめぐって一時期争っていましたが、マイクロソフトは離脱、SunはＶＭはやめてＪＡＶＡだけに特化してしまいましたが。ＭＯＮＯは新しい方ではないでしょうか。
一番有名なのがVM Ware。VM ware Playerなる無償版があるので、使ってみたところが以下の画像。
ブラウザみたいなウィンドウ内で別のＯＳが起動しています。（動作してるのはUbuntuというＬｉｎｕｘＯＳで、ブラウザだけしか起動しない様にしてあるヤツです。実際のＵｂｕｎｔｕはちゃんとしたＯＳです。）
将来この技術をリンデンはＳＬに使いたいと考えてるようです。＾＾。
追記:
やっぱブラウザだけしか動かないのはつまらないので、ＯＳのイメージファイルをVM Wareからもらってきて以下のようにウィンドウズの上にもう一つのＯＳ、 Ubuntu8.04を動作させました。＾＾