Second thoughts about MONO

Mono is faster...?

Heavy lifting math, bit manipulation, string processing appear to be about 80-100% faster not 100 000 times faster as was first declared - also I'm tempted to put a lot of this down to having more memory space. So well that's ok - not stunning but ok. No real revolution here.

But not too many common objects are that heavy on math etc... So ask yourself - where's the *majority* of lag coming from in this place (i.e. SL)?

For me it's obviously tImers and all things that use timers (AOs, "radar orbs" and the like, email clients, self-animated objects like robots, pets, etc). Specifically llSetTimerEvent and llSensorRepeat.

Some testing on the preview grid show that these critical lag monsters will run 5% SLOWER than on the current LSL VM.

Thoughts? Is this mono stuff going to *increase* the lag issues rather than reduce them? And if so -- what was the point of all this?

/esc

Another annoyance - llGetFreeMemory STILL returns historical memory - so is still basically useless.

Personally, I'm happy to take a 5% performance hit in scripts if it will open the door for alternate scripting languages and some of the new features that appear to be in the pipeline. I rather doubt the slow down is going to happen though. **shrug**

Keep in mind this is the beta grid. It's not exactly running the top of the line hardware that the main grid is. That 5% may in fact be due to hardware differences.

aye 5% slower? than what?

not to be a wiseacre but how much slower do scripts run without mono on the beta grid, ive never measured but it was noticeable

so if it was 20% slower 5% seems freakin awesome

The differences were measured using over 200 identical scripts compiled first to standard then to mono, so it was a direct comparison on the same simulator.

/esc

Apparently I have some scripts that went from a good 30s calculation time to immediate response when compiled to mono.

So I would say that there is quite a noticeable performance gain there.

And we are talking several thousand scripts running there.

I've tested objects of mine that used timers, obviously the Tummy is one of the main ones and I did not notice any lag.

In all truth everything was more speedy and responsive compared to the main grid.

I would love to see llGetFreeMemory work like its SUPPOSED to.

Do you really think a lot of people would complain if it actually returned a real value, even when freed from now on? Its not like it would affect the OLD scripts compiled pre mono, those would still function as is on the old script processor anyhow.

if you demand to suck at scripting and to cause lag with many short timers please just cancel your account.
this thread is pointless

Amen to that!

Ok, I added a simplistic kind of measurement to ZHAO-II out of curiosity. Nothing scientific, just elapsed llGetTime() wrapped around the checkAndOverride() function which invokes all the heavy lifting. Dilation was nice and steady at .99/1.00 in Sandbox Goguen MONO during this.

This really wasn't a fair contest, I had to run away while testing the LSL2-compiled version so the function wasn't exercised very heavily. For the Mono run, I did keep my avatar walking, stopping, flying, running, jumping to give the functions a good workout.

Even so, at first blush Mono still looks like a big win from here for this "critical lag monster".

For LSL2: passes 3500 time 362.424103 mean 0.103550 [this was running closer to 0.12 before I had to go idle]

For Mono: passes 3500 time 66.042830 mean 0.018869

As said, the measurement was simplistic, just for curiosity's sake. Two globals:

integer passes = 0;
float timeused = 0;

and checkAndOverride modded as follows:

integer checkAndOverride() {
    //XXX
    if(passes)
        if (!(passes % 100))
            llOwnerSay("passes " + (string) passes + " time "
                + (string) timeused + " mean " + (string) (timeused / passes));
    float thistime = llGetTime();
    passes++;
    if ( animOverrideOn && gotPermission ) {
        // Check if we should explicitly NOT override a playing animation
        if ( hasIntersection( autoDisableList, llGetAnimationList(Owner) ) ) {
            startNewAnimation( EMPTY, noAnimIndex, EMPTY );
            timeused += llGetTime() - thistime;
            return FALSE;
        }

        animOverride();
        timeused += llGetTime() - thistime;
        return TRUE;
    }
    // (didn't bother checking here because I left the AO on and had permission)
    return FALSE;
}

Please let me know how to create a decent walk without an AO/Short Timer, or how to receive object emails without some kind of timer (assuming no manual intervention).
BTW it's generally not length of the timer delay per se that truly lags the sim (assuming you write efficient code), it's the number of timers running.

Yep the performance characteristics are quite different. Some scripts are a lot faster, others slower.

What I was actually doing was not timing functions (tho I did some experiments using that method too) but rather looking at the overall effect on the sim script time (ctrl-shift-1/scripts). That method is more heuristic but also it seems more realistic. I found that I could only run 200 or so of these scripts on the preview sim before the simulator "capped" the script time skewing the results. Obviously this overhead that I observed would only appear slowly as scripts are recompiled in-world, but it definitely concerns me that I'm seeing the effect.

/esc

Beware of the script time and operations stats, they are unreliable if the sim is otherwise under low use.

more at https://lists.secondlife.com/pipermail/secondlifescripters/2008-June/003141.html

Interesting link -- AFAICS I think what karen said there is that these numbers should be interpreted carefully -- in the case of that discussion, it was essentially "don't equate IPS directly to lag/sim load", so if I'm reading it right, she's not really saying that the numbers are unreliable. However, it does raise the caution that the amount of time *allocated* to running scripts may not be directly related to sim load or "lag" - though in my experience... it does

best,
/esc

multiple timers in a single script, to trigger some functions of the same script less often than others:

---
complex, large, tricky, flexible in accuracy and performance:
Not performance tested but I have done some PARALLEL TIMERS within a single script, their function is basically "do X after at least N time has passed", within a single script.
Then theres one integer that stores a timestamp (or a minimum delay) for every ASYNCRONOUS timed procedure.

- One script has multiple timers for different "X" procedures, each with its own variable "minimum delay".
- Time dilation can be ignored if the variables use a timestamp that is unaffected by simulator dilation.
- the region can crash or not allow scripts, but the function "do X after at least N time has passed" will work (due to the "at least" condition).
- the timer can be set longer and "do X after at least N time has passed" still works, just less accurate and each timer becomes less independent due to a larger checking interval. To increase performance over accurancy, just make the main timer longer.

"do X after at least N time has passed" can be more accurate and more flexible OR more efficient than "do X after every N dilated time", maybe even both by using mono.

--
simpler alternative for less flexibility:
make a single counter that is increased in every timer event, this can be a very short timer.
make a smart contition tree based on that counter to put multiple timed events in:
The conditions may be syntax error, they should check if an incriesed timer is a product of 2,4,8,3,9,27,5,25,125,7,49,343 intervals, multiples of prime numbers for fast exclusive condition trees.
timer++;
if ~(timer % 2){
if ~(timer % 4){
if ~(timer % {}
}else if ~(timer % 3){
if ~(timer % 9){
if ~(timer % 27){}
}else if ~(timer % 5){
if ~(timer % 25){
if ~(timer % 125){}
}else if ~(timer % 7){
if ~(timer % 49){
if ~(timer % 343){}
}
for more flexibility include larger prime numbers in "else if()"-statements

-
best of both above (assuming that listen channel filters are worth a centralized timer):
make communication relays to call your own standart time for events. One timer per region, events are triggered by listening to that "world time".
The "world time" uses multiple channels, each for their own prime-number-interval.
A "world time server" identifies itself and makes all other siblings in range to its "clients" to centralize the timers within its range.
-> timers are still set and triggered by a server as in the first method above, just more centralized and syncronized.
-> the listen channels for clients are set as in the second method above, ignoring all irrelevant intervals and quickly filtering the relevant intervals.

With respect Olij --I think you are missing the point here. This thead isn't about how to code up a timer or make it efficient. The issue is that it appears that, when compiled for/recompiled to the Mono VM, then existing or future scripts that use timers (which are already the major lag contributors to a sim) will increase lag/sim load rather than decrease it.

Hope that clarifies.

regs,
/esc

Where the heck is this "timers are the biggest lag inducers" coming from again?! O.o That's one of the most bogus things I've ever heard of. Timers are a heck of a lot less costly than listens, sensors, HTTP requests, and any number of other things. They don't cause frequent costly 3D geometry calculations constantly like sensors and (many) listens/chats do. Have you ever looked at the script time used up by an object using multiple scripts to cause "smooth" non-physical movement?

Now what people DO inside a timer event could easily be costly. No debate about that. Timers might be used more and trigger more frequently than other events (reasonably likely). But don't blame timers themselves. That's just silly, and there's no evidence I've ever seen implying anything of the sort.

Did one heck of a lot of testing when Mono was first out, including timers. Everything was just about as fast as was projected with only two exceptions; state changes and database calls. The only reason database calls are slower is because of the Aditi asset system which, at it's best, is an order of magnitude worse then the MG asset system on a bad day.
Reading notecards, updating scripts, rezzing objects are all iffy.

So this leaves only lowly state changes. It has been 3 or 4 months since I have checked and hopefully even that problem has been addressed. At that point in time, MONO regions were seperate from Havok 4 regions also, so there was also some disparity in anything involving physics.

So I agree with Hewee, just exactly what are you doing in your timer events?

Still want to say it is timers then try this, two scripts in the same prim and try it multiple times. After you look at the results then go digging in the scripts you were testing and find the real problem:

integer count = 1;
       
       default
       {
           touch_start(integer total_number)
           {
               llResetTime();
               llSetTimerEvent(5.0);
           }
           timer()
           {
               if(count == 50){
                   llOwnerSay("MONO VM took seconds" + (string)llGetTime() + " seconds");
                   //llOwnerSay("LSL VM took seconds" + (string)llGetTime() + " seconds");
                   llResetScript();
               }
               else
                   count ++;
           }
       }

what the hell is a state change (sarcastic tone)

oh i guess i should explain i dont use states unless theres a real advantage, not to change alpha to 4 different values

ive always thought that they were abit clunky on the system, and that people should learn how to count in their scripts before using a "flip to this page" interactive book approach

Fancy sort of "jump" command??????????????

In LSO changing state does a couple things, first you flush the event queue and queue the state_exit, then you set the state register to the new state.

When an event is being queued, the queing mechanism first checks the event against the combined event mask, then it looks at the state register which is just the number of the active state, that number is used as the index for the state table, where it checks if the event can be handled by that state (each state has it's own event mask).

When an event is dequeued and executed, the script does again reads the state register, gets the event mask, by counting bits turned on, it works out what number event of handled events it is. It then uses that number as the index in a lookup table for the particular state and executes the block of code at the address in the table.

In Mono... I don't really know what madness they are using but it won't be the same madness.

I suspect they are using function pointers and a table or maybe just reflection. Can't say for sure. The former could be slow if not implemented properly. The later would just be slow regardless.

---

Anyway, why would you want to use states, there are so few situations where you really want to nuke the event queue and not loose script status.

I use states heavily in a parser I've been writing. Since I'm having to read the input one character at a time I find it's a lot better, as I don't need a huge tree of if-statements every time a new character is read. I don't have a performance comparison between the two though, as my initial attempt using a huge if-statement tree to get parse-mode etc. became so unwieldy there were bugs everywhere that I was struggling to fix, re-writing as states seemed the sensible thing to do. But I suppose it's a minority case, as I only process link-messages in a single 'idle' state so losing the event queue doesn't matter to me, as my parser only ever does one thing at a time; I have a messaging structure that accounts for the potential missing messages.

I find as a coding structure states are invaluable in LSL, however if I were doing it in Java I would use objects I think, since it's just a case of having an object with a common interface and swapping in the appropriate one at each stage.

Three things:
1) I'm talking about *sim lag* not "script lag".

2) You are not reading my OP correctly, in particular:

"...ask yourself - where's the *majority* of lag coming from in this place (i.e. SL)? For me it's obviously tImers and all things that use timers (AOs, "radar orbs" and the like, email clients, self-animated objects like robots, pets, etc). Specifically llSetTimerEvent and llSensorRepeat."

...now certainly an open listen on channel 0 is a lag monster but not other listens - repeated (i.e. on a timer) HTTP requests may indeed lag a sim - so for my money timers and timed events are the real culprits of in-world sim lag.

3) Applying the words "bogus" and "silly" to my statements is not just offensive but shows that you haven't thought this issue through yet. I've been scripting here for years and I have a fair amount of experience. I do not consider my statements ill-considered.

regs,
/esc

/me nods "states do some things well"

I would do everything with objects and interfaces given the opportunity.

Interop would be so much fun to design, If I were designing the system I would consider using MS's new contract based system with some extra syntax sugar on top.

namespace LL
{
    class LSL
    {
        T llWorldMessage<T>()
    }
}

namespace MyCode
{
    #using LL;
    interface MyInteface{
        void OrderPizza(string address)
    }
    class Program
    {
        void state_entry()
        {
            llWorldMessage<MyInteface>().OrderPizza("Here");
        }
    }
}

llWorldMessage would return an object that would be an instance of the interface but the methods would really just be a wrapper over the event queuing code. Which would look something like...

The object returned by llWorldMessage could be cached in a dictionary so it wouldn't need to be rebuilt on each call, the initial call would be expensive because you would be constructing the object dynamically. The advantage of this approach is that your code is type safe and the syntax isn't overbearing. Once you had it working properly, it would be *fast*.

class partial ScriptVM
{
    QueueEvent(Type myInterface, MethodInfo mi, object [] parameters)
    {
        scripts.Where(script => script.ActiveInterfaces.Contains(myInterface)).Queue(mi, parameters);
    }
}

Ooooh Idea...

You could do it with ducktyping, including states ^_^

I was doing precisely nothing in the timer events. The issue here is the sim overhead not the the script performance (which of course will be adversely affected in a loaded sim).

As to *why* this is so? I don't know; but ff I were to make a bet, I think the underlying issue is that event scheduling for a script compiled to MONO is more processor intensive than for a script compiled to the LSL2VM.

regs
/esc