Second thoughts about MONO
|
|
Strife Onizuka
Moonchild
Join date: 3 Mar 2004
Posts: 5,887
|
08-02-2008 10:48
From: Escort DeFarge 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 I guarantee that event queuing is more costly in Mono.
_____________________
Truth is a river that is always splitting up into arms that reunite. Islanded between the arms, the inhabitants argue for a lifetime as to which is the main river.
- Cyril Connolly
Without the political will to find common ground, the continual friction of tactic and counter tactic, only creates suspicion and hatred and vengeance, and perpetuates the cycle of violence.
- James Nachtwey
|
|
Jesse Barnett
500,000 scoville units
Join date: 21 May 2006
Posts: 4,160
|
08-02-2008 10:50
From: Escort DeFarge 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 Post the script you were using Escort. I and I am sure others would be interested in digging into this more.
_____________________
I (who is a she not a he) reserve the right to exercise selective comprehension of the OP's question at anytime. From: someone I am still around, just no longer here. See you across the aisle. Hope LL burns in hell for archiving this forum
|
|
Escort DeFarge
Together
Join date: 18 Nov 2004
Posts: 681
|
08-02-2008 11:04
The script was basically this... default
{
state_entry()
{
llSetTimerEvent(10.0);
}
timer()
{
// do nothing
}
} The acid test is - using the same sim - when compiled to LSL then MONO, how many of these does it take to max out the sim? /esc
_____________________
http://slurl.com/secondlife/Together
|
|
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
|
08-04-2008 09:51
From: Strife Onizuka I would do everything with objects and interfaces given the opportunity. I'm really hoping the move to Mono means we might eventually get a language where objects are at least possible, even if the language itself isn't as heavily object-oriented as the likes of Java and C#. A properly organised class library for SL would be AWESOME, as currently LSL is going the way of PHP with lots of function names to remember that aren't named as consistently as they could be. I probably program too much when I get excited by the thought of being able to do Simulator.getRegionFPS() and stuff like that  If I ever do get this parser of mine finished I'll be releasing it open-source. It's pretty powerful so may be of use to others =)
_____________________
Computer (Mac Pro):
2 x Quad Core 3.2ghz Xeon
10gb DDR2 800mhz FB-DIMMS
4 x 750gb, 32mb cache hard-drives (RAID-0/striped)
NVidia GeForce 8800GT (512mb)
|
|
Osgeld Barmy
Registered User
Join date: 22 Mar 2005
Posts: 3,336
|
08-04-2008 10:37
ugh i hate stuff like that
it could be handy yes, but right off in your eaxample its Uppercase.lowercaseUppercase()
ugh, luaplyer for the psp is like that and i cant remember which one is upper and lower and upper or which one is a class (.) or a operator(: ) of that class or if that operator is upper or lower case
i just went tru a stinkfest about that on their forums regarding the new version
then where does it stop are we really wanting LL.Uupper.lowerUpper() cuase im too stupid to know its a LL function that deals with the simulator?
blah
|
|
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
|
08-04-2008 11:17
Well, the typical convention (though stupid M$ decided to go with their own of course) is to start class/type names in upper case and start function/method and variable names in lower case. It is the Java coding convention and it was by far the most widely used convention in C++ and several other languages as well. Then the beginning of each word is capitalized while the remainder is lower case. Conventions differ a bit as far as acronyms in the name go, but usually you can adjust well enough to how it is done by different libraries. There would be no need for any kind of ll/LL in the function names, as the class scope would disambiguate it from any 'getRegionFPS()' function you might write. Most likely there WOULD be a LL in the name of the class (LLSimulator.getRegionFPS()) or a namespace in which the classes reside (e.g. LL.Simulator.getRegionFPS()). It's not very difficult to get used to such a convention, and you'd be building good programming skills in doing so, and it would more than likely be consistent across the whole LSL function library.
Anyway, there was a survey a month or three back about how we would rank various scripting enhancements after Mono is delivered, and several of the points were related to C# and direct method calls between scripts in the same prim and such. Cross your fingers!
|
|
Darien Caldwell
Registered User
Join date: 12 Oct 2006
Posts: 3,127
|
08-04-2008 12:57
From: Escort DeFarge The script was basically this... default
{
state_entry()
{
llSetTimerEvent(10.0);
}
timer()
{
// do nothing
}
} The acid test is - using the same sim - when compiled to LSL then MONO, how many of these does it take to max out the sim? /esc I don't know that I would call a script that does nothing an acid test. But I'll say it again, A lot of the beta grid is Class 4 hardware, and Comparing Old LSL to New LSL would show some significant differences, as would comparing New LSL to New Mono. But the real important comparison would be comparing Old LSL to New Mono. That will show you the figure everyone actually cares about. From my tests (and I've been working on the mono progject since it went live on Beta), Mono is just as good if not faster than Old LSL. |
|
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
|
08-04-2008 13:26
From: Darien Caldwell But the real important comparison would be comparing Old LSL to New Mono. When you talk about "New" and "Old" LSL do you mean LSL and LSL2? Because to me that seems unusual; most people now are using LSL2 so the only relevant statistic is how Mono compares to that. LSL2 as I understand it is basically just an interpreted language, it does no native compilation; the scripts are compiled to bytecode which is easier to interpret, but is never compiled natively (unlike Java bytecode). Mono however is compiled isn't it? Or at least it uses just-in-time compilation from bytecode, thus after running a script once it should be a lot faster. If it isn't then something's not right at all, but if the case is that it's events that are the problem then I suspect there is some technical issue in presenting events to a Mono script.
_____________________
Computer (Mac Pro):
2 x Quad Core 3.2ghz Xeon
10gb DDR2 800mhz FB-DIMMS
4 x 750gb, 32mb cache hard-drives (RAID-0/striped)
NVidia GeForce 8800GT (512mb)
|
|
Osgeld Barmy
Registered User
Join date: 22 Mar 2005
Posts: 3,336
|
08-04-2008 21:24
From: Hewee Zetkin Well, the typical convention (though stupid M$ decided to go with their own of course) is to start class/type names in upper case and start function/method and variable names in lower case. It is the Java coding convention and it was by far the most widely used convention in C++ and several other languages as well. Then the beginning of each word is capitalized while the remainder is lower case. Conventions differ a bit as far as acronyms in the name go, but usually you can adjust well enough to how it is done by different libraries. There would be no need for any kind of ll/LL in the function names, as the class scope would disambiguate it from any 'getRegionFPS()' function you might write. Most likely there WOULD be a LL in the name of the class (LLSimulator.getRegionFPS()) or a namespace in which the classes reside (e.g. LL.Simulator.getRegionFPS()). It's not very difficult to get used to such a convention, and you'd be building good programming skills in doing so, and it would more than likely be consistent across the whole LSL function library.
Anyway, there was a survey a month or three back about how we would rank various scripting enhancements after Mono is delivered, and several of the points were related to C# and direct method calls between scripts in the same prim and such. Cross your fingers! yea but its the exact oppsite of simple scripting in another thread i sympathized with a noobie who was not interested at all in writing an OS for lsl just to do simple things now your wanting me to be a pro at C++ and java just to get the simulator fps, its a pita enough for non coders, that would add in YET another layer of complication the system, really does not need come on, seriously if im calling "get region fps" do i need to add syntax and add in more typing just to signify that "get region fps" is a simulator function, isnt that kinda already implied, do i need to type more crap to remind me that a region is a simulator, and are you willing to explain that to total script virgins who just want to add a switch to their doo hicky? its fine without classes, were not going to be able to include any libs we happen to copy into a notecard and expand the system indefinitely, and AFAIK theres not even any plans to add any support for other languages, its totally back end, that whole idea that wont die was a 1 liner almost 3 years ago about the thought process, and never mentioned offically since boils down to if you want to script lsl, your in the right place, want to do C++ do us all a favor and write a client with bug fixes and better water lsl needs to be simplified for its userbase, ie a drag n drop lego system, just like clothing can make a shirt out of a square texture, then if you want to be a pro, then be a pro with whats there now, when i dont have to spend 4 hours explaining {}()!=>< to a noob who just wants a ball to spin THEN we can talk about adding class systems |
|
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
|
08-04-2008 22:05
From: Osgeld Barmy yea but its the exact oppsite of simple scripting
in another thread i sympathized with a noobie who was not interested at all in writing an OS for lsl just to do simple things
now your wanting me to be a pro at C++ and java just to get the simulator fps, its a pita enough for non coders, that would add in YET another layer of complication the system, really does not need That's not at all what I said. It is a useful convention which is not hard to learn. Just like you now know that all LSL library functions begin with the prefix 'll'. Trust me, it won't be difficult to get used to a slightly different convention. Heck, you almost have "classes" or "namespaces" already in the way the functions are organized by categories on the wikis. When I referred to other languages, I was emphasizing that there is a GOOD convention for capitalization that has been developed over DECADES by computer scientists and programmers for GOOD REASONS. They encourage good coding practices and very readable code. And the great thing is that in learning such conventions in the course of scripting for SL, you'd also be growing skills you would find useful if you DID choose to do any development, "out in the real world." And finally, I hate to be the bearer of bad news, but SL is FAR from a SIMPLE system in which to do development. With all the stupid little gotchas and complex workarounds and such, I would have to say it is actually one of the hardest places to program there is. Most systems actually have straightforward ways for doing most things.  |
|
Osgeld Barmy
Registered User
Join date: 22 Mar 2005
Posts: 3,336
|
08-04-2008 22:19
From: Hewee Zetkin That's not at all what I said. It is a useful convention which is not hard to learn. Just like you now know that all LSL library functions begin with the prefix 'll'. Trust me, it won't be difficult to get used to a slightly different convention. Heck, you almost have "classes" or "namespaces" already in the way the functions are organized by categories on the wikis.
lsl is already hard for the simplest of task's, why add another layer of confusion to it From: someone
When I referred to other languages, I was emphasizing that there is a GOOD convention for capitalization that has been developed over DECADES by computer scientists and programmers for GOOD REASONS. They encourage good coding practices and very readable code. And the great thing is that in learning such conventions in the course of scripting for SL, you'd also be growing skills you would find useful if you DID choose to do any development, "out in the real world."
ok chosen, not everyone is desiring to be a total GOD of their domain, i learned most of my modern scripting from lsl, and breaking the habbits of a simple scripting system to a more complex form is not that hard, just becuase i learned it 1 way does not mean its always that way if i used that logic id still be typing in 10 ? "hello world" but i dont also just becuase its been "done for decades" doesnt neccacarly mean its a good idea, go ask a 70 year old minority From: someone And finally, I hate to be the bearer of bad news, but SL is FAR from a SIMPLE system in which to do development. With all the stupid little gotchas and complex workarounds and such, I would have to say it is actually one of the hardest places to program there is. Most systems actually have straightforward ways for doing most things. i hate to be the bearer of bad news, as a fairly accomplished scripter in php, sdlbasic, python, lua (6 flavors) and now picking up C, LSL is very simple, even with the gotcha's, tell me when i needed a thread callback or 4 different syntaxes to script lsl (i need 4 syntaxes to script any given lua program) just becuase you choose to make it difficult (and you do mr 2 pages to make a light switch) doesnt meant the rest of us do, lsl is supota be a SIMPLE scripting language, its far from it now, and adding unneeded crap to it later just makes things worse |
|
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
|
08-04-2008 23:54
From: Osgeld Barmy ...lsl is supota be a SIMPLE scripting language, its far from it now, and adding unneeded crap to it later just makes things worse No, LSL is supposed to allow you to create a wide diversity of applications within the SL world, and that's far from simple. EVERY language and library aims to some degree at simplicity and understandability, but has to balance that with the complexity of the tasks it is designed to accomplish. You argue that object orientation is an additional layer of confusion and complexity, but I respectfully disagree. Organizing functionality into cohesive units tends to DECREASE confusion. Imagine you could do the following:
LL.Agent agent = LL.Agent.forKey(id);
vector size = agent.getSize();
string name = agent.getName();
LL.Camera cam = agent.getCamera();
cam.setPosition(pos);
|
|
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
|
08-05-2008 06:41
Crap! It seems that state-changes on Mono servers is really slow under both LSL2 and Mono! I'm getting state-change performance 200 times worse than I currently do on the main-grid. Can someone please confirm that this is the case? You can use the following script to get a rough timing: integer counter = 0;
default {
state_entry() {
llResetTime();
state state1;
}
}
state state1 {
state_entry() {
state state2;
}
}
state state2 {
state_entry() {
if ((++counter) >= 100) {
float time = llGetTime() / 200.0;
llOwnerSay((string)time + " seconds/state-change");
} else state state1;
}
} I'm getting 0.000232 seconds per state-change in what I would consider a typical region. However, on the Mono grid I'm getting 0.022 seconds per state-change (both using the above script) in an empty region with almost no script activity. I've noticed as the result of some benchmarking I'm running. My observations thus far are as follows (note that by operations I mean basic additions/subtractions etc., not function calls): Loops: 6-7 times faster under Mono. Integer operations: 4,000-5,000 times faster under Mono. Float operations (add, subtract, divide, multiply): 3,000-4,000 times faster under Mono. Vector operations (add, subtract, dot-product, cross-product): 10,000-11,000 times faster under Mono. Rotation operations (multiply, divide, rotate vector): 60-70 times faster under Mono. List operations (clear, assign, append*): 65,000-66,000 times faster under Mono. String operations (clear, assign, append): 2,500-2,600 times faster under Mono. Key operations (assign): 10,000 times faster under Mono Casts (to and from all possible primitive types): 110-120 times faster under Mono. State transitions: 200 times worse on Mono servers for both Mono and LSL2 scripts =( Function calls: Immeasurably faster than LSL2. Events (timer): Approximately the same under both LSL2 and Mono. Link-messages: Approximately 1% slower under Mono. I'm using a fairly simple benchmarking script I made to get performance measurements, it gets very reliable results on the main-grid for raw script performance, so I trust its results on the preview grid as well. *List append adds empty list entries until there are 25 entries, before clearing the list and starting again for a total of 40 such iterations.
_____________________
Computer (Mac Pro):
2 x Quad Core 3.2ghz Xeon
10gb DDR2 800mhz FB-DIMMS
4 x 750gb, 32mb cache hard-drives (RAID-0/striped)
NVidia GeForce 8800GT (512mb)
|
|
Jesse Barnett
500,000 scoville units
Join date: 21 May 2006
Posts: 4,160
|
08-05-2008 07:02
I ran a variation of the same test last night with 50 itinerations in both MONO and LSL and my numbers weren't that bad. Try a different region? I've been testing in Svarga in Aditi. From: Haravikk Mistral Crap! It seems that state-changes on Mono servers is really slow under both LSL2 and Mono! I'm getting state-change performance 200 times worse than I currently do on the main-grid. Can someone please confirm that this is the case? You can use the following script to get a rough timing: integer counter = 0;
default {
state_entry() {
llResetTime();
state state1;
}
}
state state1 {
state_entry() {
state state2;
}
}
state state2 {
state_entry() {
if ((++counter) >= 100) {
float time = llGetTime() / 200.0;
llOwnerSay((string)time + " seconds/state-change");
}
}
} I'm getting 0.000232 seconds per state-change in what I would consider a typical region. However, on the Mono grid I'm getting 0.022 seconds per state-change (both using the above script) in an empty region with almost no script activity. I've noticed as the result of some benchmarking I'm running. My observations thus far are as follows (note that by operations I mean basic additions/subtractions etc., not function calls): Loops: 6-7 times faster under Mono. Integer operations: 4,000-5,000 times faster under Mono. Float operations (add, subtract, divide, multiply): 3,000-4,000 times faster under Mono. Vector operations (add, subtract, dot-product, cross-product): 10,000-11,000 times faster under Mono. Rotation operations (multiply, divide, rotate vector): 60-70 times faster under Mono. List operations (clear, assign, append*): 65,000-66,000 times faster under Mono. String operations (clear, assign, append): 2,500-2,600 times faster under Mono. Key operations (assign): 10,000 times faster under Mono Casts (to and from all possible primitive types): 110-120 times faster under Mono. State transitions: 200 times worse on Mono servers for both Mono and LSL2 scripts =( Function calls: Immeasurably faster than LSL2. Events (timer): Approximately the same under both LSL2 and Mono. Link-messages: Approximately 1% slower under Mono. I'm using a fairly simple benchmarking script I made to get performance measurements, it gets very reliable results on the main-grid for raw script performance, so I trust its results on the preview grid as well. *List append adds empty list entries until there are 25 entries, before clearing the list and starting again for a total of 40 such iterations.
_____________________
I (who is a she not a he) reserve the right to exercise selective comprehension of the OP's question at anytime. From: someone I am still around, just no longer here. See you across the aisle. Hope LL burns in hell for archiving this forum
|
|
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
|
08-05-2008 07:12
From: Jesse Barnett I ran a variation of the same test last night with 50 itinerations in both MONO and LSL and my numbers weren't that bad. Try a different region? I've been testing in Svarga in Aditi. I just tried all the MONO enabled regions and all seem equally as bad =(
_____________________
Computer (Mac Pro):
2 x Quad Core 3.2ghz Xeon
10gb DDR2 800mhz FB-DIMMS
4 x 750gb, 32mb cache hard-drives (RAID-0/striped)
NVidia GeForce 8800GT (512mb)
|
|
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
|
08-05-2008 10:00
For those interested I've posted a JIRA issue, please add any findings of your own and vote for it! I'm getting mixed results of between 10 and 100+ times as slow as non-Mono regions for state-changes, which is quite significant! http://jira.secondlife.com/browse/SVC-2750
_____________________
Computer (Mac Pro):
2 x Quad Core 3.2ghz Xeon
10gb DDR2 800mhz FB-DIMMS
4 x 750gb, 32mb cache hard-drives (RAID-0/striped)
NVidia GeForce 8800GT (512mb)
|
|
Darien Caldwell
Registered User
Join date: 12 Oct 2006
Posts: 3,127
|
08-05-2008 11:55
From: Haravikk Mistral When you talk about "New" and "Old" LSL do you mean LSL and LSL2? Because to me that seems unusual; most people now are using LSL2 so the only relevant statistic is how Mono compares to that.
LSL2 as I understand it is basically just an interpreted language, it does no native compilation; the scripts are compiled to bytecode which is easier to interpret, but is never compiled natively (unlike Java bytecode). Mono however is compiled isn't it? Or at least it uses just-in-time compilation from bytecode, thus after running a script once it should be a lot faster. If it isn't then something's not right at all, but if the case is that it's events that are the problem then I suspect there is some technical issue in presenting events to a Mono script. The LSL that is sitting alongside Mono in Mono enabled regions is the New LSL. It's not the same as the Old LSL, what is currently running on the main grid. For the most part its the same, but it shares the same Memory optimizations as Mono does, where a script only uses as much memory as it needs, ect. And it seems to be a bit worse off on some things as it seems you are discovering. |
|
Escort DeFarge
Together
Join date: 18 Nov 2004
Posts: 681
|
08-05-2008 12:10
From: Darien Caldwell The LSL that is sitting alongside Mono in Mono enabled regions is the New LSL. It's not the same as the Old LSL, what is currently running on the main grid. For the most part its the same, but it shares the same Memory optimizations as Mono does, where a script only uses as much memory as it needs, ect. And it seems to be a bit worse off on some things as it seems you are discovering. Hmm - so the new Mono Sim RC will actually an updated LSL2 VM as well as a MONO VM? A "double beta" then... (eeps!)? If so, I see no way to make any sensible comparison! Any chance you can you let us know how you got the comparative results that you mention Darien (i.e. between the production LSL2 VM and both the updated LSL2 VM and MONO)? regs, /esc
_____________________
http://slurl.com/secondlife/Together
|
|
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
|
08-05-2008 12:12
Crazy. But realize too that if the absolute number of about 0.02 seconds per state change is correct, that's not bad at all. 0.05 seconds is supposed to be the minimum period between events, so you're lucky you can even get the 'state_entry' of successive states to fire faster than that. A state change being faster than the minimum period between events is not bad at all IMO.
|
|
Darien Caldwell
Registered User
Join date: 12 Oct 2006
Posts: 3,127
|
08-05-2008 12:25
From: Escort DeFarge Hmm - so the new Mono Sim RC will actually an updated LSL2 VM as well as a MONO VM? A "double beta" then... (eeps!)? If so, I see no way to make any sensible comparison!
Any chance you can you let us know how you got the comparative results that you mention Darien (i.e. between the production LSL2 VM and both the updated LSL2 VM and MONO)?
regs,
/esc By hopping back and forth between the Main grid and the Beta grid. I own a number of sims so I have the benefit of controlled conditions on the main grid. It's by no means a perfect comparision, but some things the difference is quite apparent. I myself mostly looked at Void sims, if you want to talk to someone who has made some extensive comparisions between old and new LSL, talk to Moon Metty.  |
|
Escort DeFarge
Together
Join date: 18 Nov 2004
Posts: 681
|
08-05-2008 13:48
From: Darien Caldwell By hopping back and forth between the Main grid and the Beta grid. I own a number of sims so I have the benefit of controlled conditions on the main grid. It's by no means a perfect comparision, but some things the difference is quite apparent. I myself mostly looked at Void sims, if you want to talk to someone who has made some extensive comparisions between old and new LSL, talk to Moon Metty. Sounds like we don't have a fair chance here. I think I'll just wait and see. If I'm right I can wear a t-shirt that says "told ya so", if I'm not then I'll simply be happy and welcome the new era.
_____________________
http://slurl.com/secondlife/Together
|
|
Talarus Luan
Ancient Archaean Dragon
Join date: 18 Mar 2006
Posts: 4,831
|
08-05-2008 16:53
From: Jesse Barnett I ran a variation of the same test last night with 50 itinerations Wow, that must have been a LONG journey! O.o |
|
Jesse Barnett
500,000 scoville units
Join date: 21 May 2006
Posts: 4,160
|
08-05-2008 17:55
Still don't understand what is going on: integer i = 1;
default{
touch_start(integer total_number){
llResetTime();
llSetTimerEvent(2.0);
}
timer(){
if ( i < 10){
i++;
state next;
}
else{
float time = llGetTime();
float cycle_time = time / i;
float ms = cycle_time - 2;
llOwnerSay("Total time = " + (string)time + "\nCycles = " + (string)i + "\nCycle time = " + (string)cycle_time + "\nms per state change = " + (string)ms);
llResetScript();
}
}
}
state next{
timer(){
i++;
state default;
}
} Ran it multiple times and sometimes LSL is a little bit faster and other times, MONO wins the race. MONO is slower the first time it is run but time drops after that. This was pretty much the norm: MONO sim: "[17:20] MONO: Total time = 22.013930 Cycles = 11 Cycle time = 2.001266 ms per state change = 0.001266 [17:20] LSL: Total time = 22.014139 Cycles = 11 Cycle time = 2.001285 ms per state change = 0.001285 [17:21] MONO: Total time = 22.014070 Cycles = 11 Cycle time = 2.001279 ms per state change = 0.001279 [17:21] LSL: Total time = 22.014654 Cycles = 11 Cycle time = 2.001332 ms per state change = 0.001332" LSL sim: "[17:26] LSL: Total time = 22.023148 Cycles = 11 Cycle time = 2.002104 ms per state change = 0.002104 [17:30] LSL: Total time = 22.027918 Cycles = 11 Cycle time = 2.002538 ms per state change = 0.002538" Sim conditions change rapidly even in an empty sim running 1.6ms script time(Svarga 600 meters). Here are multiple runs with just MONO to see the variation: "[17:40] MONO: Total time = 22.039540 Cycles = 11 Cycle time = 2.003594 ms per state change = 0.003594 [17:41] MONO: Total time = 22.016680 Cycles = 11 Cycle time = 2.001516 ms per state change = 0.001516 [17:43] MONO: Total time = 22.047010 Cycles = 11 Cycle time = 2.004274 ms per state change = 0.004274 [17:44] MONO: Total time = 22.027920 Cycles = 11 Cycle time = 2.002538 ms per state change = 0.002538 [17:47] MONO: Total time = 22.018990 Cycles = 11 Cycle time = 2.001726 ms per state change = 0.001726" 100 scripts compiled in MONO at same location running at the same time and the script time never varied from 1.6 ms. "[17:53] MONO: Total time = 22.018480 Cycles = 11 Cycle time = 2.001680 ms per state change = 0.001680 [17:53] MONO: Total time = 22.018480 Cycles = 11 Cycle time = 2.001680 ms per state change = 0.001680 [17:53] MONO: Total time = 22.018480 Cycles = 11 Cycle time = 2.001680 ms per state change = 0.001680 [17:53] MONO: Total time = 22.018480 Cycles = 11 Cycle time = 2.001680 ms per state change = 0.001680 [17:53] MONO: Total time = 22.018480 Cycles = 11 Cycle time = 2.001680 ms per state change = 0.001680 [17:53] MONO: Total time = 22.018480 Cycles = 11 Cycle time = 2.001680 ms per state change = 0.001680 [17:53] MONO: Total time = 22.018480 Cycles = 11 Cycle time = 2.001680 ms per state change = 0.001680 [17:53] MONO: Total time = 22.018480 Cycles = 11 Cycle time = 2.001680 ms per state change = 0.001680 [17:53] MONO: Total time = 22.018480 Cycles = 11 Cycle time = 2.001680 ms per state change = 0.001680 [17:53] MONO: Total time = 22.018480 Cycles = 11 Cycle time = 2.001680 ms per state change = 0.001680 [17:53] MONO: Total time = 22.018480 Cycles = 11 Cycle time = 2.001680 ms per state change = 0.001680" etc. etc. etc......................... As a footnote I ALWAYS have the statistics window open when testing in Aditi.
_____________________
I (who is a she not a he) reserve the right to exercise selective comprehension of the OP's question at anytime. From: someone I am still around, just no longer here. See you across the aisle. Hope LL burns in hell for archiving this forum
|
|
Jesse Barnett
500,000 scoville units
Join date: 21 May 2006
Posts: 4,160
|
08-05-2008 18:12
From: Talarus Luan Wow, that must have been a LONG journey! O.o EDIT OOOps, Iterations!( dyslexia sucks!. Didn't even notice misspelling after you pointed it out at first.) 
_____________________
I (who is a she not a he) reserve the right to exercise selective comprehension of the OP's question at anytime. From: someone I am still around, just no longer here. See you across the aisle. Hope LL burns in hell for archiving this forum
|
|
Thraxis Epsilon
Registered User
Join date: 31 Aug 2005
Posts: 211
|
08-05-2008 19:24
From: Darien Caldwell The LSL that is sitting alongside Mono in Mono enabled regions is the New LSL. It's not the same as the Old LSL, what is currently running on the main grid. For the most part its the same, but it shares the same Memory optimizations as Mono does, where a script only uses as much memory as it needs, ect. And it seems to be a bit worse off on some things as it seems you are discovering. I've not seen any post from a Linden stating that the LSL VM will be changed when MONO goes to the grid. |