What's MONO Good For? What's MONO Bad For?

heyas;

the 'second thoughts about mono' thread is very interesting and WAY too technical for me! ;) so how about breaking it down a bit?

as i understand, the only thing mono does is calculate things faster. does this in any way mean that we can now do llsetpos/rot or llsetprimitiveparams faster than 5 frames per second? that's THE big question, for me. i expect not. ::sigh::


if your script doesnt do any calculations, is it better to just not go to mono? oh, lets say it just does menus on touch. and pre-set stuff. is it WORSE to convert it to mono? does it matter?


do any sorts of scripts NEED to stay NON-mono? you know, like in the ancient old days when you went from a 33 mhz processor to a 66 mhz and all your 4-colour games played twice as fast and became uncontrollable?

Function delays won't change any. MONO is mainly good for anything that does a lot of arithmetic and other primitive operations. Anything that relies on a function is theoretically unaffected, though of course in MONO calling a function is now faster, but the inner workings of the function itself are much the same.

Basically; if you do lots of maths in your script then it helps a lot. If your script spends most of its time executing LSL functions (the built-in ll* ones) then it won't see much of a boost in performance.

Even if they're mathematical functions? llAxes2Rot, llPow, etc? How about list operations?

I have a lot of scripts that doesn't do hard math, but uses a lot of functions instead. On those scripts mono actually seem slower, but then there are the memory management thats supposely better on mono, so I'm not quite sure if recompiling is better or worse.

I'm noticing in estate tools that scripts I convert to Mono are taking twice the millisecond sim time of their LSL counterparts.

Anyone have any findings on this?

I've noticed that too. Here are a few tests done with estate tools on a class 5 sim:


Idle Script (only state_entry())
---------------------------------
Mono: 0.003
LSL: 0.000

- Timer (0.2 and assingning a var)
---------------------------------
float v;

state default
{
state_entry()
{
llSetTimerEvent(0.2);
}

timer()
{
v = 1.0;
}
}
Mono: 0.008
LSL: 0.001

- Link Message (sender and receiver)
--------------------------------------
// Receiver
default
{
link_message(integer sender_num, integer num, string str, key id)
{

}
}

// Sender
key null = NULL_KEY;

default
{
state_entry()
{
llSetTimerEvent(0.2);
}

timer()
{
llMessageLinked(LINK_SET,0,"sending",null);
}
}

Mono: 0.025
LSL: 0.008

- For loop
-----------------------------------------
float v;

default
{
state_entry()
{
integer i;
for(i = 0; i < 100000; ++i)
{
v = 1.0;
}
}
}

Mono: 0.040
LSL: 0.145

- Timer, SetPrimitiveParams and list
list pos_rot = [];
float dpos = 0.5;

default
{
state_entry()
{
pos_rot = [llGetPos(),llGetRot()];
llSetTimerEvent(0.2);
}

timer()
{
llSetPrimitiveParams([PRIM_POSITION,llList2Vector(pos_rot,0)+<0.0,0.0,dpos>,PRIM_ROTATION,llList2Rot(pos_rot,1)]);
dpos *= -1.0;
}
}

Mono: 0.014
LSL: 0.004

A script that uses a few matematical functions in a timed event:

default
{
state_entry()
{
llSetTimerEvent(0.2);
}

timer()
{
rotation currRot = llGetRot();
vector localX = llRot2Fwd(currRot);
vector localY = llRot2Left(currRot);
vector localZ = llRot2Up(currRot);
vector dir = llVecNorm(<200.0,0.0,0.0> - llGetPos());
rotation desiredRelativeRot = llAxisAngle2Rot(localZ, llAtan2(dir * localY, dir * localX));
llRotLookAt((currRot * desiredRelativeRot), llGetMass(), 0.1);
}
}

Mono: 0.019
LSL: 0.004

I think many of the normal info displays and timers normally used to gauge performance (which are often interpreted incorrectly anyway) aren't properly set up for Mono yet.

Anyhow, from personal experience, Mono scripts run faster. I'd just compile to Mono and not worry about whether you're eking out that extra 0.001% efficiency if you're making small, uncomplicated scripts. For larger projects, it's almost certainly worth switching to Mono.

As for all the comments on slower state changes, I can't really disagree with the research done, but.. if you're making a script that needs to constantly and quickly switch states, relying on the fraction of a second difference in time, you're probably doing it wrong. States are for polymorphic event behavior on a larger scale, not for abusing for small transactions at high speeds..

Hi Bloodsong,

Great idea for a discussion, and for most probably of more value, though I do appreciate the technical stuff too

In my case I have concentrated mainly in storage and communications as that is where my interest lays and have found that benchmarks have shifted a lot during the beta phase, mostly to the worst.

But to answer the bigger question, I see no reason NOT to use MONO. In the short term the immediate savings may not be much for the individual script but several lower level factors come into play that may/will have a major impact down the line, from my understanding.

Probably the most important is that if several copies of the same script is run in a simulator, that script is only loaded into the simulator once and is then run as often as required. This is not a short term benefit as it only, to my understanding, applies to a script with the same asset ID, so if you recompile 2 objects containing the same script it's still 2 scripts, but if you compile it in MONO and copy it into 1000 objects its still one script as far as the server/simulator is concerned.

The second of course the new functionality, the llDetected Touch functions and the proposed llDialogueInput which will revolutionise a lot of applications and I doubt will be retrofitted to legacy LSL.

And finally we have the potential to have MONO Libraries and even additional languages added to the scripts tool kit.

One day LL 'may' turn off the old LSL runtime, although I don't think that is likely to happen. But if there is no downside to compiling your scripts to MONO, which hopefully this thread will help determine, then why continue to create new content for the old platform.

My opinion, is that if you are writing new scripts, compile to MONO, if you have older scripts test them on MONO and see if you get any benefit, if you have an ancient script that you don't even support any longer then let it ride.

As I said at the start I am more of a systems programmer, I look forward to comments from those who work with Physics.

Just wondering how many times the scripts were run to get those results. I'd run them 10 times if it was me just to get a more even number and eliminate some of the hiccups in SL at times.

My personal experience on the beta grid re-running scripts is that (counterintuitively) the LSL scripts seemed to improve on time and the mono ones didn't... work that one out! Shouldn't it have been the other way around what with JIT compiles etc????

/esc

Yeah, one would thinks so. Sl is a continual mystery though.

- String to list parsing on mono is 1.5-4 times slower on mono (llParseString2List,llParseStringKeepNulls,llCSV2List)

- Link Message handling on mono is different than LSL. Both in timing and in queue handling

I recompiled Jesse's long distance TP script and it works really well under Mono. In the LSL engine, it would stop on the way in some sort of limbo, in Mono it is just instant.

Its the only script I've tried and its definitely much faster and better under Mono in my experience.

Just crashed my sim, but works fine...

I've recompiled a list-manipulation heavy script and found no difference in speed. However, a stripped-down (i.e - not correctly functioning but fits into LSO-LSL's memory) version of my AES implementation runs around 1000 times faster in Mono, as it's heavy on byte manipulations such as XORing values.

LL functions should not change in speed at all, as they're already running on the simulator I think so are likely compiled natively in C or something so should be fairly optimal for both LSO-LSL and Mono (though sometimes I wonder). Mono can do set-up for function calls a lot faster though, and captures return values more quickly I think to, but on the whole it's not much different time-wise as the bulk of the time is spent IN the functions themselves.

The tests are not 100% accurate. I did do several of them (refresh), and just pasted in the value that seemed to happen the most. There were however no instances where mono were faster in all tests except the for loop:

About functions executing at the same speed on mono and LSL:

integer i = 0;
float time = 0.0;

default
{
touch_start(integer total_number)
{
float _time = llGetTime();
llPlaySound("3281f769-0ed0-ea83-ecc0-7d1fc25cb65e",1.0);
time += llGetTime()-_time;
++i;

if(i > 9) {
time = time/10.0;
llOwnerSay("Mono: "+(string)time);
}
}
}

Mono: 0.034524
LSL: 0.024602

I do know that there are many things happening that is untestable, amongst others the memory managment. These are just raw script execution times.

Catten, your test really should be performed a few times in a loop for a proper measurement, as Mono typically performs slowly the first time a block of code is executed, as it uses a "just in time" compiler.

I created a script that tests a ton of things, it's a bit much to post here as it has a few helpers for link-messages. However, I basically found that once the overhead of a function itself is removed, that Mono has an extremely small set-up time before the function is executed, when compared to LSO-LSL.

You'r right about the loops. All the previous tests are done in estate debug, and should not show the overhead. I redid the above with a call to the same function in state_entry and the result were the same. I'm not 100% sure, but I'd imagine that the overhead (where some simple functions will take up to 0.2ms to execute) only happens if they are tested on state_entry?

What's Mono good for? At this point, absolutely nothing, as far as I'm concerned.

So far the Mono rollout has been the single biggest disaster I've ever faced as a content creator, and we (the Combat Samurai Island team) now have more than nineteen thousand customers with horribly broken content.

I have no words for how upset I am.

Having said that, Mono has tremendous potential, and I welcome having access to the finished product when that becomes available. I can see many benefits, which have already been well-described by many other people.

But Mono today is an epic failure.

I should clarify something... The Mono rollout broke *existing* content. The scripts that were supposed to just keep running as they always had before? Every state change is taking 5 seconds, where there was no noticeable delay. The scripts operated without problems for the last two years, then when the rollout came, performance dropped straight into the toilet.

Message queing from server calls Robby?

Already heard from someone this morning stating:

"they have out some type of throttle in there that we don't know about. I have a couple screen fulls of data I output. which starts out fast then crawls at the end. even the messages display out of order some time."

Anybody else got any more info/tips on the estate debug tools? I just recompiled some fairly simple scripts from LSL2 to Mono (1.21 RC0 client) and noted the same thing others have mentioned -- the Mono-scripted object was reported as taking up a significantly larger time-slice (2-3x) than the same object w/ scripts compiled in LSL2. I also noted, however, that the "Mono time" column was still showing 0.000. My assumption is that the "top scripts" listing isn't quite handling things right just yet...

I don't have any script timing/performance monitoring code in the scripts in question atm, so I don't have any feel for how fast the script is actually executing. I wouldn't really expect these scripts to be significantly impacted by Mono -- not much math etc., but a timer repeatedly firing off link messages causing some ll* function calls.

Cyn

just to add

my simple door script that has been working without a hickup for as long as i can remember gets stuck half way open

my vista ao is lagging behind to a pint i fly standing straight, misfired flight animation to a point of ruth walking animation wich all ran fine befor mono

seeing more weird script behaviors but those are random, overall, c r a p


had my mind set to some of my work public with a rewrite to mono so it can be used in a single script to escape the linkedmessage work around for memory but starting to wonder why to even bother...

also i hate windlight and all the crap and never changed from nicholaz`s 1.18.5, 1 more reason personally not to touch it...

My experience of things so far...

What is mono good for? Haven't honestly found a useful script that runs any better under mono than under LSL.

What is mono bad for? Recompiling to mono seems to *increase* script idle time (as seen in the estate tools) at between 150-250%. Given that most scripts will spend most (nearly all) of their time in idle, i'd say this was the biggest single potential issue. My biggest concern is that as more scripts get compiled to mono, the worse the effect on sim script time will be and the perceived sim lag in-world will potentially get twice as bad as now given no other changes.

I've also seen some evidence of link message weirdness under mono but have yet to nail down where that's coming from - I suspect it's back to the "event scheduling" responsiveness issue that I spoke of in another thread.

/esc