Talk:Mono

Mono Benchmarks

I notice that the benchmarks listed seem to mostly be numeric. Has anyone done any benchmarks on string and list processing? Lee Ponzu 08:36, 4 February 2008 (PST)

I was testing some encoding and decoding functions I wrote and ran both versions sided by side. Very string intensive. The Mono version finished the full circuit before the LSO had code finished the encoding.

Other languages

Here's a question about mono that the article doesn't address: Will scripters be limited to LSL or will they be able to code in C# or something else more Mono-like? --Steamy Latte 12:20, 22 January 2008 (PST)

Until LL can ensure that Mono is properly sandboxed and secure, the compiler will remain server side and the only language available will be LSL. -- Strife Onizuka 12:40, 23 January 2008 (PST)

That makes total sense. Your comment does make it sound like there's a future plan to add other languages, after adequate testing has taken place. If so it's good news, as LSL lacks OOP and is cumbersome by comparison. --Steamy Latte 09:53, 24 January 2008 (PST)

In 16k you don't want OOP. Trust me. The overhead would be killer. I just want pass by reference. Pass by value is the worst feature of LSO. If I had to guess I would say that most of speed improvements come from pass by reference alone. -- Strife Onizuka 17:19, 24 January 2008 (PST)

Agreed! We would be able to leverage so much more from the sad 16kb we get if we could do address operations and pass by reference. Oh, a second question there. Will the maximum size of scripts be increased? Jana Kamachi 09:55, 26 January 2008 (PST)

I don't know. One advantage of the new system is that script asset transfers will be faster for the vast majority of script, they won't be statically allocated to 16kb. This means sim crossings should be faster. -- Strife Onizuka 15:56, 26 January 2008 (PST)

You sure? Serializing a mono script is a lot more work than serializing an LSL2 script, because the LSL2 script is basically serialized already. My concern has been that the cost of sim crossings with Mono scripts would likely be *higher*. I notice that in the Mono demos the Lindens have not shown a sim crossing for an avatar running Mono scripts: Babbage turned around before the edge of the sim in the one scene that looked like he might venture one. I hope they have multiple *adjacent* Mono-enabled sims in Beta. -- Argent Stonecutter 12:25, 28 January 2008 (PST)

Good point, I hadn't taken that into consideration. But if the script is a slave script without globals and not currently in an event that it won't have a stack or variables allocated. It should result in very little that needs serializing. I'm curious which system has a faster serialization of the event queue. -- Strife Onizuka 16:21, 28 January 2008 (PST)

I'm just looking forward to using Python. I wonder if LL will give any sort of time frame (like late Q1, a few weeks after Mono releases, we'll be adding it during beta...) for adding other languages. I'd appreciate a little more script overhead so I could go nuts making class objects (like I normally do to make my life easier), but I suppose that will be subject to thorough testing as to whether any scripts currently in existence can push that 64kb cap. I'm also hoping sockets are retained, I'd like to be able to open connections to outside servers for whatever purposes I'd need. -- Feynt Mistral 09:32, 30 January 2008 (PST)

Compile Data Flow

Can someone describe the way the current flow works, and how the new flow will contrast. That is, I think at present:

1. You edit on the viewer.
2. When you [save], the source is uploaded.
3. A compiler in the viewer creates bytecode.
4. The bytecode is uploaded.

Is this correct? How will this change, if at all? Lee Ponzu 09:20, 26 January 2008 (PST)

I can't be sure of this but the new system would be:

1. You edit on the viewer.
2. When you [save] and check the Mono checkbox, the source is uploaded.
3. Upon receiving the script some server (sim or centralized compiler?) compiles the script to CIL bytecode.
4. The bytecode is saved.

Strife Onizuka 16:01, 26 January 2008 (PST)

Strife has it correct. The compilation is done by a process running on each mono-enabled sim host. Periapse Linden 12:20, 30 January 2008 (PST)

Optimization

Oddly enough different .net functions that do basically the same things run at different speeds. It may be of interest to read this article: StringBuilder vs. String / Fast String Operations with .NET 2.0. The information may not be totally applicable with Mono but it should get you thinking. -- Strife Onizuka 17:31, 4 April 2008 (PDT)

Why is this page referring to LSL2, and not LSO ?

To my knowledge, the old scripting engine is LSO VM, which requires LSO bytecode. In various locations on this page, I see LSL2 being mentioned, for example Performance benchmark tests show that Mono is up to 220 times faster than LSL2.. Shouldn't LSL2 be replaced with LSO ? I find the term LSL2 somewhat misleading, as it implies to me that there's a difference in the actual scripting language (LSL) depending on whether the script is going to compiled in Mono or LSO bytecode.PixelProphet Lane 16:51, 11 February 2012 (PST)

It is the difference between LL's internal names and what turns up on the public side. This appears in other places too, for example public documentation uses "physical and nonphysical" objects while Lindens talk about "dynamic and static". There has been a profound communication disconnect between LL and its customers for years and years, the documentation warts are small artifacts of a much bigger problem. --Cerise Sorbet 20:57, 11 February 2012 (PST)

That problem stems from STATUS_PHYSICS etc. LL has been terrible at naming things in LSL. Poor interface design. -- Strife ^{(talk|contribs)} 23:39, 18 February 2012 (PST)

I popularized calling it LSO, at the time we only knew of LSL2 as the language, in hind sight that may not have been the case. When Mono was being rolled out I had a problem, when writing about the old VM, what do I call it. There were two issues here: In the bad old days things didn't really have well defined edges, there was one changelog for both the server and client. Likewise, LSL as a language, compiler and VM were all a package. There was an LSL1, and the LSO VM still supports it but there isn't a compiler for it. So where did LSO come from? LSO was the (internal) asset type for a compiled script. So the question is: Is it the LSL2 VM (which is down compatible with LSL1 LSO) and LSL2 language (not down compatible with LSL1 language) using the LSO type for it's compiled assets; or is it the LSL2 language (not down compatible with LSL1) and the LSO VM (which runs LSL1 & LSL2 LSO compiled scripts). The second solution is a lot less complicated and is what I assumed was correct. There is likely no correct answer to this as LSL2 may never have been given a tight definition and scope. I might have been wrong but until today I had never considered it. I will say it is easier to refer to it as LSO since the first fundamental difference between the two VMs is the type of bytecode they run. This is the sort of thing you could ask at the Beta Server Office Hours.

-- Strife ^{(talk|contribs)} 23:35, 18 February 2012 (PST)