Scripted Behavior: Mono Vs. LSL Maze-Off!

Here's a compelling side-by-side action video comparing the Linden Script Language and Mono, which will soon supplant LSL as Second Life's official in-world scripting code.  The video was created by Amanda Levitsky, who also coded the generating maze program.  "The maze thing is just a toy I made some time ago," she tells me. "it felt like a good fit for testing Mono though, due to the computational nature of it."  And lo, the Mono-powered Maze on the right finishes rendering in about a minute.  Heading toward the 4 minute mark, LSL is still sputtering to finish.

Not being a hardcore techie, I asked Amanda how she could run SL-driven programs with two separate coding languages rights next to each other.  "Mono-enabled regions still have the LSL virtual machine (I guess this makes it less likely to break existing scripts when Mono reaches the main grid)," Amanda Levitsky tells me. "If you save a script with the 'Mono' checkbox ticked, it'll run on Mono, and otherwise it'll run on the old LSL implementation."  With demos like this, I'm guessing that option will soon go the dodo's direction.

Comments

[Ahab Schmo]

http://blog.secondlife.com/2008/04/15/mono-beta-refresh-8/

Has another video comparing speed! It got burried by service updates pretty quickly.

[Dedric Mauriac]

One thing that I really like about mono is the errors are more detailed about where your script failed by spitting out a stack trace.

[Patchouli Woollahra]

The removal of the original LSL bytecode machine will not happen for a while. for the SL scripting community to switch fully to Mono, LSL scripts will need to be recompiled. This is not possible in certain cases currently:

1) if the original pre-compile LSL code is missing (due to asset losses - a rare occurence these days admittedly), and the only thing keeping the script ticking over in practice is the bytecode that was generated off it, recompiling the script to support Mono is currently not possible.

2) there needs to be a fall back in case it turns out that introducing a Mono implementation creates issues that need to be addressed which impact on how LSL is parsed and how it affects the world which are not desirable. Not all the bugs in LSL currently are bugs that must be fixed - there's a couple that have become behaviors on which plenty of content rests, and they have jumped into becoming actual features.

Babbage Linden has previously mentioned that the team implementing Mono is making an effort to find ways to transparently recompile original LSL bytecode to that produced by Mono so that making the switch from LSL Original to Mono becomes something transparent. Which IMHO would be a good thing.

[Patchouli Woollahra]

But what happens if calculation isn't an essential aspect of the transform, but object update functions such as llMoveObject?

Todd Borst exposes a slight flaw in Mono LSL as currently in beta. it's subtle, but it's there.

http://www.massively.com/2008/04/17/lsl-vs-mono-deathmatch/

[TigroSpottystripes Katsu]

I know this is a bit old, but i felt I should mention this, the scripting language will not be changed witht he implementation of mono, it will still be lsl, what is changing is the system that will run the scripts