Mono can be slower

//Jesse
integer x; 

default {
	touch_start(integer num_detected) {
		llResetTime();
		x = 0;
		state run;
	}
}
state run
{ 
    state_entry() 
    { 
        if (x >= 0 && x <= 5){
            if (x == 0) {++x;}
            else if (x == 1) {++x;}
            else if (x == 2) {++x;}
            else if (x == 3) {++x;}
            else if (x == 4) {++x;}
            else if (x == 5) {++x;}}
        else if (x >= 6 && x <= 10){
            if (x == 6) {++x;}
            else if (x == 7) {++x;}
            else if (x == 8) {++x;}
            else if (x == 9) {++x;}
            else if (x == 10) {++x;}}
        else if (x >= 11 && x <= 15){
            if (x == 11) {++x;}
            else if (x == 12) {++x;}
            else if (x == 13) {++x;}
            else if (x == 14) {++x;}
            else if (x == 15) {++x;}}
 
        if (x < 16){
            state loop;}

        else {
            float elapsed = llGetTime();
			integer mem = 16000 - llGetFreeMemory();
            llOwnerSay((string)elapsed + " elapsed time" + " & " + (string)mem + " bytes");
			state default;}    
    }
        
} 
state loop{
    state_entry(){
        state run;
    }
}    

Regular compile:
[17:01] Object: 0.978298 elapsed time & 810 bytes

MONO compile:
[17:01] Object: 1.311735 elapsed time & -44088 bytes

Multiple test cycles, always same results.

Now same test in a regular sim:
[17:08] Object: 0.311743 elapsed time & 810 bytes
[17:08] Object: 0.311408 elapsed time & 883 bytes
[17:08] Object: 0.311471 elapsed time & 888 bytes
[17:08] Object: 0.312520 elapsed time & 888 bytes
[17:08] Object: 0.311451 elapsed time & 888 bytes
[17:08] Object: 0.311734 elapsed time & 888 bytes

So although MONO will definitely be faster in most cases, even after all the bugs are worked out, it will still be slower in some cases.

What you're doing should never be done by anyone, in LSL2 or Mono. Especially the switching states thing.



Also, try running a loop over a larger number of iterations.

All this was, was an old script where we bench marked different ways to do else if tests, not the way I would code something. Except for the nested else ifs, nesting else if isalways much faster then running straight through, harder to code yes, but faster.:

/54/02/144383/1.html

And itinerations don't matter, still slower. Consistent with some of the anaylsis by Argent, Taran & Dzontas in scripting mailing list on what we should expect. IN several cases our old virtual machine will be much faster.

Now of course some things it will be faster on, such as:

integer x = 0;
integer y = 1000000;

default {
    touch_start(integer n) {
        llResetTime();
        while (x != y) {x++; y--;}
        llOwnerSay((string) llGetTime());
        llResetTime();
        x=0;
        y=1000000;
    }
}

Go smoke a cigarette while waiting on it to run in LSL. But in MONO/LSL2 it only takes 5 or less seconds.

BTW: please don't try this in the MG, that is what beta is for.


For list and string manipulations there should end up being no change in the amount of time it takes to process.

If you insist on THAT CRAPPY coding, to try to prove a pointless point, nothing can help you.
In case you didnt notice, your argumentation a logical fallacy.

this is like attacking the weak point of that giant enemy crab for massive damage.

not STFU plz.

ANd just who's alt are you? LOL

My goodness!

Feeling a little like an asshole today?

might as well test ugly code, since that's the majority of what will be used.

nevermind that it's actually better for the comparison testing than the effecient code, because it kicks the VM harder, and therefore expands the scale of the comparison.

it's not like she tested different VM's with different code. ::eyeroll::

now what I got from it is that mono doesn't handle stacked if/else's as well as the current VM, or it could be the state changes, heck it could be ANY test.

the point wasn't to to show proper coding, it was to hilight the difference in how the different VM's reacted to certain circumstances. point being, the mono VM is choking on something in there compared to the current VM.

Ah heck I am not worried about them. I am just having fun in mono. As pointed out if they had followed the link, that code was from about a year and a half ago. First time I was supremely proud with myself and LSL. My "crappy" code was faster then an old timer's code. Not the way I would do it today but it illustrates the point.

Some thing are unbelievably faster. Took forever to get results but that second script that was actually taking 2.5 seconds or less in mono(definitely not bad for a million itinerations), took 5 minutes in a regular sim

But I may have to change my viewpoint on list/string manipulations:

list test;

default {
	state_entry() {
		integer a = 1;
		while (a < 250) {
			test += a;
			a++;
		}
		llListRandomize(test, 2);
		llListSort(test, 2, TRUE);
		string b = llDumpList2String(test, ",");
		test =[];
		test = llParseString2List(b,[],[","]);
		llOwnerSay((string) test);
		llOwnerSay((string) llGetTime());
	}
}

Took 6 seconds but only 0.06 in mono.

interesting, but don't be hasty, it could be better string/list handling. but it could also be a better sort implementation (AFT) or a worse/broken randomizer (bets anyone?)

And forgot to expand on what Void said. I spent about a year exclusively in beta, hunting bugs and testing code. Know most of QA and a proud member of Dan Linden's Bug Hunter's group. You WANT to try to break the simulator and crashing one is even better. That's the point. The nastier the code the better. This is how you find what works and what doesn't.

Instead of people getting mad; Please come to beta and test and try to break things yourself. Don't take anyone's word on what MONO can or can't do(including Linden's). Find out for yourself and post and share.

Fixes that are caught in beta can be fixed in days as compared to months once they are incorporated into the MG servers.

Agreed, Jesse. It's always good to try to throw everything you can at the wall and see what sticks. Then scrape it off with a squeegee before it has time to dry.

I figure the extra time is due to the state changes. They are likely not implemented very efficiently in Mono because they are a LSL peculiarity that Mono probably would have a hard time supporting natively. Have you tried the same code sans state changes and seen if it is faster?

I'm not being angry, I agree with your strategy; I already hardcore broke Mono, and the bugs have since been fixed. I was just making a note for the less informed that code should never look like that in practice.

On another note, I haven't yet tested string or list operation times comparatively between LSL and Mono, but I am curious whether string operations (at least the most important one for me, llSubStringIndex) are still faster than similar list operations, as they are under LSL in my tests. It's more beneficial if string operations are faster than lists anyway, IMO, as lists are a massive waste of precious memory.

One thing to note is that in benchmarking on multiprocessing systems (which definitely includes SL), it is better to test the number of operations in a fixed amount of time rather than the amount of time it takes to complete a fixed number of operations. This tends to reduce the effect of system interruptions on the results.

Also, I'd be interested in seeing an analysis of the times between iterations. It could be that Mono is interrupting script execution for very long periods periodically, but that most iterations are very fast. Maybe run a bunch of iterations that simply get timestamps and add them to a list until X seconds have passed, then spit out the times (and differences, because the script might as well do its own post-processing).

Mono is, as of yet, NOT optimized.

Right now priority lies on getting everything working properly.

Then, and ONLY then will LL focus on optimizing the code.

Not yet but I will tonight and also break it down to single operations, repeatedly called to see which ones are the bottleneck, including empty state changes.

But this is still the most fun I have had for ages in Aditi and it's good to be back. I had a chance to pop in there the first day but very little of what I had would even run and sims would last 5 minutes. But then again, for just the second server update, it is much more steady now then I would have expected for another month yet. Still a looooooooooooong ways to go though.

In case there was confusion, I mean I hope they run an optimizer on compiled LSL code. If not, the door is wide open for it, so I'd rather use good coding practices and let a few extra CPU cycles accumulate here and there until the code can be optimized.

Meant to check state changes last night but someone forgot to throw a bit flag when they updated the MONO regions yesterday and couldn't compile to MONO in any of the four regions.

Simple script, 1000 itinerations (default to next and then back). As was surmised by Void, Talarus and others. MONO just doesn't handle state changes well. Be an interesting exercize to change an AO over to global variables from multiple states. Think I might try it with my Flight Assist.

integer a = 0;

default {
	state_entry() {
		if ((integer) a < 500) {
			a++;
			state next;
		}
		else
			llOwnerSay((string) llGetTime());
	}
}
state next {
	state_entry() {
		state default;
	}
}

Still don't know what to call it so guess maybe LSL1 & MONO?
LSL1:
[18:31] Object: 22.235405
[18:31] Object: 22.235252
[18:32] Object: 22.235853
MONO:
[18:32] Object: 33.376300
[18:33] Object: 33.377430
[18:34] Object: 33.376860
LSL1:
[18:34] Object: 22.415228
[18:35] Object: 22.405502
[18:35] Object: 22.401039
MONO:
[18:36] Object: 33.402730
[18:37] Object: 33.373590
[18:38] Object: 33.522910

Now look at the dramatic(expected but still dramatic) difference switching over to global variables instead:

integer a = 0;

global_one(){
    if ((integer) a < 500) {
        a++;
        global_two();
    }
    else
        llOwnerSay((string) llGetTime());
}

global_two(){
    global_one();
}

default {
    state_entry() {
        global_one();
    }
}

LSL1:
[18:56] Object: 0.400460
[18:56] Object: 0.400396
[18:56] Object: 0.400380
MONO:
[18:56] Object: 0.133569
[18:56] Object: 0.044688
[18:56] Object: 0.022379
LSL1:
[18:56] Object: 0.400504
[18:56] Object: 0.400584
[18:56] Object: 0.400542
MONO:
[18:56] Object: 0.117499
[18:56] Object: 0.045919
[18:56] Object: 0.023162

Don't understand yet why MONO results aren't consistent in this case, but instead, returns decreasing values. Have to mull that one over for awhile.

What viewer were you using? I accidentally logged in with the Windlight viewer and couldn't figure out for quite some time why the darn checkbox wasn't there....

LL dweebs. Each state should just be another object which overloads one or more methods in a--drum roll--State Pattern! Switching states should call state_exit, switch a reference, and call state_entry on the new State (actually possibly an internal function that switches listens and a few other small things before calling the user's template state_exit and state_entry methods). What, all of about 0.05 MICRO-seconds should be required....

Anyway, sorry for the rant. Couldn't help it. Heh heh.

Oh. God. By the way, do you realize that your recursive implementation isn't very friendly to ANY LANGUAGE OR PLATFORM?! You've got like 1000 levels on the call stack. That's never good. State changes don't compare; the VM doesn't have to remember what states it came from and undo each transition. I wouldn't blame SL if it threw rotten veggies at you for that and gave a script error to boot. Think iterative, not recursive.

I was using Second Life 1.18.6 (7796, which is the beta viewer and I tried multiple times throughout the night to login Thursday night. All with the same result, I did have the checkbox for MONO there, but it was grayed out. THis is what you are supposed to have in a region that is not running MONO.

It's not the first time and won't be the last that someone forgot to set a bit flag correctly when updating the code in Aditi. Eventually they figured it out and reset it and yesterday everything worked correctly.

Now as for the rest of the comments. Unbelievable that I am having to explain this again. The title of this thread is "MONO can be slower", not "How to code for LSL". Several of us, hopefully many others are testing MONO in Aditi. That is why it is there. You try to find the difference in how code runs both ways and hopefully spot "bugs". The only way to do that is throw code at it, a lot of code. Whenever you find code that doesn't work or that is slower in MONO then you break it down to it's constituent parts to find what is the offending function. Then you test each function and to get consistent results you do it in a lot of intinerations and then try it multiple times to account for any variables such as sim performance which can change moment to moment.

The theory was already raised that MONO may not handle state changes as well. But until you apply the scientific principle and test it, it is only a theory.

Again, I DO KNOW HOW TO CODE PROPERLY and this is not it. But it is the proper way to test the VM. I Do know that that were 1000 state changes, because I told it to go through 1000 state changes.

I am not mad, but am more then slightly perturbed that some people do not understand this and repeatedly point out the "bad" coding.

Sorry if it came off that way. I've test plenty of code myself, and I was teasing more than anything. I'm actually surprised (pleasantly?) you didn't get some kind of stack overrun error. And I certainly wasn't critisizing your testing where the long state changes were concerned. Just responding out of shock at the results. LOL. I'm actually wondering if they might use state changes as a yield point, to give up processing time to the system and other executing scripts.

that would make a certain sort of sense... thankfully most of my state changes in scripts are aimed at occuring in dead zones, but I can see how it would hurt some people. then again my largest use of state changes is in locking out input during initialization (notecard reads), and closing dialog listens after timeouts... neithr of which have high impact on performance (since one time effects and disuse really don't harm much even if they took an extra second or two)

Nope, apology comes from me, thought you were criticizing the method, not the outcome. Guess I am still kind of in shock myself after the initial responses in the thread.

Forgot to mention that you do actually run into a stack-heap collision somewhere over 500 itinerations. Hadn't thought about but would probably agree also on it being a yield point. Interesting to see if Strife has any insight into it.

On average we will still be much faster with MONO then LSL, but of course I feel the need for speed and want to squeeze as much out of it as possible. There is a really good flight assist script in the library which I have been using for last year and a half. It uses multiple states and has piqued my interest as a candidate of switching over to global variables instead of state changes.

In some cases we we still be forced to use different states or it might be easier, but in others, it might just be a case of being creative with a single timer.