Second thoughts about MONO
|
|
Darien Caldwell
Registered User
Join date: 12 Oct 2006
Posts: 3,127
|
08-06-2008 11:58
From: Thraxis Epsilon I've not seen any post from a Linden stating that the LSL VM will be changed when MONO goes to the grid. I attend the Mono office hours every Friday. It was during one of these office hours that Periapse Linden revealed that LSL now benefits from the same memory optimizations that Mono will have. I will see if those particular office hours have been posted to the Wiki. If you only read the blogs, you are only getting about 5% of the information.  Edit: I don't see any transcripts posted since Mid March. I will come back and post from my own logs once I get home this evening. Or feel free to ask Periapse, Babbage, Scouse, Vektor, or any of the other Mono team members. |
|
Osgeld Barmy
Registered User
Join date: 22 Mar 2005
Posts: 3,336
|
08-06-2008 16:43
ive only seen it stated once, back well before they were talking about actually implementing it, since mono supports different language sets and translates them to the same VM instantly everyone was like
OMFG I CAN WRITE LSL IN PHP
BOUT FKIN TIME I WROTE JAVA TO LSL
EVERY BENEFIT OF CPP WILL BE IN LSL THANK YOU THANK YOU!!
almost 2 years ago i heard, "it might be possible" and people wont let it DIE, it in all probability wont, from the get go the function of mono in SL was to speed up the lsl vm, nothing else
LET IT DIE you will not be able to include a header on a notecard and add open GL to a prim, nor add arrays or any othe magical horse crap thats ever been mentioned
|
|
Viktoria Dovgal
…
Join date: 29 Jul 2007
Posts: 3,593
|
08-06-2008 16:58
From: Osgeld Barmy almost 2 years ago i heard, "it might be possible" and people wont let it DIE, it in all probability wont, from the get go the function of mono in SL was to speed up the lsl vm, nothing else O RLY? http://blog.secondlife.com/2005/04/26/tla-bingo/From: someone This allows us to take advantage of the advanced features of the Mono runtime like Just In Time (JIT) compilation to improve the performance of LSL execution, to extend LSL more easily and ultimately to allow the use of multiple programming languages and class libraries within SL. Only a few weeks ago the Lindens asked us what features they wanted us to work on first, and the the support for other languages was still there. |
|
Jesse Barnett
500,000 scoville units
Join date: 21 May 2006
Posts: 4,160
|
08-06-2008 19:25
3 year old blog post, carrot is still dangled every now and then and then I'll hear some other Linden stating no way in heck. I think there is a great deal of discord amongst the Lindens as to implementing other languages and as nice as arrays would be I would rather see other projects done first.
So my take on "ultimately" is that it translates to years down the road.
_____________________
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
|
|
Viktoria Dovgal
…
Join date: 29 Jul 2007
Posts: 3,593
|
08-06-2008 20:07
Most if not all the support for other languages is already going to be there, that will have been an inevitable result of writing the new LSL compiler and plumbing it all into the simulators. The Mono project itself took so long because it was halted midway through, but the hugest chunks of hard work will be behind them now.
|
|
Osgeld Barmy
Registered User
Join date: 22 Mar 2005
Posts: 3,336
|
08-06-2008 20:33
ok thanks for proving me wrong, it was 3 YEARS ago, and not 2 my bad |
|
Viktoria Dovgal
…
Join date: 29 Jul 2007
Posts: 3,593
|
08-06-2008 20:45
It wasn't just some random person who made this up, it's the person who's been implementing LSL on Mono all this time, and he's still saying stuff like that. And he seems to know what he's talking about, he got it to work and everything!
|
|
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
|
08-06-2008 21:11
On June 25, 2008, the Lindens conducted a survey about LSL project priorities for after Mono was delivered. The discussion thread is here, though the survey itself is over: /54/92/267068/1.htmlSomething like half the survey questions were about bringing C# and related libraries/functionality to SL. While that's certainly not a promise, it's an awfully big investment in user opinion, and an awfully big poster to wave in front of users' eyes, if they DON'T have it as a pretty big priority. |
|
Darien Caldwell
Registered User
Join date: 12 Oct 2006
Posts: 3,127
|
08-06-2008 22:17
Here's the Section from the office hours, I was finally able to find it in my megs of logs hehe: From: someone [2008/06/20 15:20] Baron Nowhere: http://blog.secondlife.com/2008/06/18/mono-beta-refresh-11/ -- blog post 42 [2008/06/20 15:20] Baron Nowhere: Argent Stonecutter Says: June 19th, 2008 at 12:13 PM Cold@24: the mono memory limit is 64k, because it’s less memory-efficient than LSL2: CIL code can be three times as large as the equivalent LSL2 bytecode. Increasing the memory limit by a factor of four is intended to cover the worst case and still leave some headroom. [2008/06/20 15:21] Baron Nowhere: I thought I read on the mono wiki page that we were getting 64kb in an attempt to allow designs with fewer scripts and fewer linked messages [2008/06/20 15:21] Baron Nowhere: could you help describe the rationale behind the 64kb, and describe what code practices drive up memory usage in mono? [2008/06/20 15:21] OoPs Galatea: Mono also uses more memroy, Baron [2008/06/20 15:21] Periapse Linden: Welcome Waster. (Lots of new faces at this office hour!) [2008/06/20 15:21] OoPs Galatea: *memory [2008/06/20 15:21] Moon Metty: hi Siann [2008/06/20 15:21] Siann Beck: Hi! [2008/06/20 15:22] Waster Skronski: Im just curroius dont mind me. [2008/06/20 15:22] Periapse Linden: Baron, it's not really code praxis that bloats the Mono bytecode, it's the nature of how Mono works [2008/06/20 15:22] Waster Skronski: Meowww [2008/06/20 15:22] Waster Skronski: *mews* [2008/06/20 15:22] Sicarius Fegte: Mono uses memory, facinating [2008/06/20 15:22] Periapse Linden: As I understand it Mono uses up a lot of memory marshalling and unmarshalling [2008/06/20 15:23] You: i can say i have many scripts that under LSL have about 4k free, now under Mono, they have well over 32k, so there is still substantial gain to be had. [2008/06/20 15:23] Periapse Linden: But Babbage could give a much better answer. Or you could go to the Mono website. [2008/06/20 15:23] OoPs Galatea: I am seeing similar results, Darien [2008/06/20 15:24] Waster Skronski: this inprovement in mem is facinating on itselfs [2008/06/20 15:24] Periapse Linden: Yes, in most cases Mono is just a little bit bigger than LSL, which means that the 64K limit gives most scripts a lot more headroom [2008/06/20 15:24] Moon Metty: and mono is dynamic, right? it doesn't always use the 64k [2008/06/20 15:24] OoPs Galatea: I think thats right moon [2008/06/20 15:24] Periapse Linden: Not only is mono dynamic, but all bytecode allocations are dynamic [2008/06/20 15:24] Periapse Linden: So now even legacy LSL bytecode uses only what it needs. [2008/06/20 15:25] Moon Metty: oh cool [2008/06/20 15:25] Siann Beck: Oh, that's cool. [2008/06/20 15:25] Waster Skronski: yup you either have to use it for stack or heap, or use more scripts to spread those. i rather like more of that, efeciency how you script inproves, even lag wise i emagin [2008/06/20 15:25] You: didn't know that, fascinating [2008/06/20 15:25] Baron Nowhere: I"m nervous because I've been scripting in a vacuum outside of the grid on design that was formerly >10 scripts and boatloads of linked messages, with a design that minimizes the messages. Now I know I need to get over here and start compiling to make sure I'm not in trouble. My precompile sizes are around 40kb [2008/06/20 15:25] OoPs Galatea: Heh, even legacy LSL isnt legacy LSL any more [2008/06/20 15:25] Periapse Linden: This ends up with a net win, since most scripts are simple things that don't use anywhere near 16K [2008/06/20 15:26] Darien Caldwell nods [2008/06/20 15:26] Periapse Linden: Lots of poseballs out there... [2008/06/20 15:26] Moon Metty: and llSetText [2008/06/20 15:26] OoPs Galatea: Yeah, it'll be great when all those Hello Avatar scripts use the space they need. [2008/06/20 15:26] Object: Hello, Avatar! [2008/06/20 15:26] Periapse Linden: lol -- yes. They all got 16K [2008/06/20 15:27] OoPs Galatea: Amazing If anyone wants the whole thing, I can provide it, I just didn't want to dump the whole giant thing here into the post. |
|
Escort DeFarge
Together
Join date: 18 Nov 2004
Posts: 681
|
08-06-2008 23:34
Frankly all that sounds like pseudotechnical gobbledegook to me... it doesn't convince me that the LSL VM has really changed at all but seems more likely from that excerpt that the speaker didn't fully understand what was going on. I wonder if I'm alone thinking that.  P.S. I think the only person's word on this I would accept would be Babbage himself.
_____________________
http://slurl.com/secondlife/Together
|
|
Darien Caldwell
Registered User
Join date: 12 Oct 2006
Posts: 3,127
|
08-07-2008 11:56
From: Escort DeFarge Frankly all that sounds like pseudotechnical gobbledegook to me... it doesn't convince me that the LSL VM has really changed at all but seems more likely from that excerpt that the speaker didn't fully understand what was going on. I wonder if I'm alone thinking that. P.S. I think the only person's word on this I would accept would be Babbage himself. Well I don't see how this sounds like gobbledegook: From: someone [2008/06/20 15:24] Periapse Linden: Not only is mono dynamic, but all bytecode allocations are dynamic
[2008/06/20 15:24] Periapse Linden: So now even legacy LSL bytecode uses only what it needs. Seems pretty straightforward. But surely there would be no harm in asking Babbage. |
|
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
|
08-09-2008 16:06
From: Hewee Zetkin 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. Hmm, is state_entry() treated as an actual event though, or is it simply fired immediately upon the state switching? state_exit() must fire immediately as it ignores the presence of other events in the queue, unless it's rushed to the start of the queue only to be fired, which seems wasteful. Anyway, this is beside the point; scripts which make good use of states will suffer if the new time is 40 to 100 times (or even more!) slower. I have a parser that heavily uses states to greatly reduce processing and make the script far more manageable, but it will suffer with these new, much slower state-changes.
_____________________
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-09-2008 18:42
From: Haravikk Mistral Anyway, this is beside the point; scripts which make good use of states will suffer if the new time is 40 to 100 times (or even more!) slower. I have a parser that heavily uses states to greatly reduce processing and make the script far more manageable, but it will suffer with these new, much slower state-changes. But they don't suffer. Look again at post #48 or try that script yourself. No variation in script or sim time and if anything, state changes were happening faster in MONO sims. It is possible that the difference is that my states aren't empty. Remember that i also had come to the conclusion that MONO was slower with state changes in the beginning, but this new data disputes that assessment. Previously, I also used an empty state to switch back and forth into, but that is recursive and is kind of a nasty trick. Any possibility MONO is treating recursion differently?
_____________________
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-10-2008 22:23
From: Darien Caldwell Well I don't see how this sounds like gobbledegook: It was -- read very carefully -- he doesn't mean bytecode allocation (which always has been dynamic if you think about it i.e. the stack) From: Darien Caldwell Seems pretty straightforward. But surely there would be no harm in asking Babbage. That's my plan
_____________________
http://slurl.com/secondlife/Together
|
|
Tyken Hightower
Automagical
Join date: 15 Feb 2006
Posts: 472
|
08-11-2008 00:04
From: Escort DeFarge It was -- read very carefully -- he doesn't mean bytecode allocation (which always has been dynamic if you think about it i.e. the stack)
He does mean bytecode allocation, which has never been dynamic - scripts under the current LSL VM always take up 16KB of space, forevar. The stack is just registers that are loaded inside of that limit. But under the new VM, both Mono and LSL compiled scripts take up only what they need, dynamically. No automatic 16KB that is largely wasted. Not that you'll be compiling many things into LSL still. Yes, LSL is changing under the hood slightly as well, because the overall VM is totally different. |
|
Deanna Trollop
BZ Enterprises
Join date: 30 Jan 2006
Posts: 671
|
08-11-2008 02:31
From: Tyken Hightower But under the new VM, both Mono and LSL compiled scripts take up only what they need, dynamically. No automatic 16KB that is largely wasted. I thought I'd read somewhere that the dynamic allocation would be in 16kb blocks, therefore scripts would still take up a minimum of 16kb. |
|
Escort DeFarge
Together
Join date: 18 Nov 2004
Posts: 681
|
08-11-2008 04:29
From: Tyken Hightower He does mean bytecode allocation... Define this "bytecode allocation"! By bytecodes I would expect that to refer to the virtual machine instructions created by the compilation of LSL - these *bytecodes* generally take up far less than 16k. What he's trying to talk about is not bytecode allocation but rather memory allocation for the object (written in c++) that represents the compiled script. It's splitting hairs but I maintain it is nonetheless pseudotechnical language. Search google and see what the phrase "bytecode allocation" returns. I suspect you'd get very little.
_____________________
http://slurl.com/secondlife/Together
|
|
Escort DeFarge
Together
Join date: 18 Nov 2004
Posts: 681
|
08-11-2008 04:32
From: Tyken Hightower Yes, LSL is changing under the hood slightly as well, because the overall VM is totally different. Only the MONO one, surely.
_____________________
http://slurl.com/secondlife/Together
|
|
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
|
08-11-2008 06:38
From: Jesse Barnett It is possible that the difference is that my states aren't empty. Your script introduces events (timers) so I'm not sure how accurate such a measurement can be. I've tried a new script which performs work within its state, in order to better simulate my parser (which only utilises the state_entry() events of each state). The following script benchmarks the time it takes to perform the fixed quantity of work (copying the contents of a string, one character at a time, into another string), so that this can be subtracted from the overall time. The script then switches between states, performing this work until done, and adjust the time to get only the approximate overhead of the state changes. string someData = "Here is some data please parse it";
integer counter = 50;
integer STEPS = 50;
float workTime = 0.0;
doWork() {
integer i = 0;
integer x = llStringLength(someData);
string s = "";
while (i < x) {
s += llGetSubString(someData, i, i);
++i;
}
}
default {
touch_start(integer x) {
if (llDetectedKey(0) == llGetOwner()) {
llOwnerSay("Getting time-estimate for loop overhead");
integer i = 0; integer x = STEPS;
llResetTime();
while (i < x) ++i;
float loopTime = llGetTime();
loopTime /= (float)STEPS;
llOwnerSay("Timing: "+(string)loopTime+" seconds/iteration");
llOwnerSay("Getting time-estimate for doWork()");
i = 0;
llResetTime();
while (i < x) {
doWork();
++i;
}
workTime = llGetTime();
workTime /= (float)STEPS;
workTime -= loopTime;
llOwnerSay("Timing: "+(string)workTime+" seconds/doWork() call");
counter = STEPS;
llResetTime();
state state1;
}
}
}
state state1 {
state_entry() {
doWork();
state state2;
}
}
state state2 {
state_entry() {
if ((--counter) <= 0) {
float time = llGetTime();
llOwnerSay(
"Time: " + (string)((time / (float)STEPS) - workTime) +
" seconds/state-change"
);
state default;
} else state state1;
}
} Here is a sampling of the results I obtained, I was only able to try two out of the MONO regions, the others were unreachable. All times are adjusted according to a measure of script performance in the region, so that faster regions are adjusted relative to the slower ones. The timings I got (running the test 10 times in each region) were as follows: Sandbox Newcomb (Mono Region): Adjusted: 0.045456 seconds/state-change Sandbox Goguen (Mono Region): Adjusted: 0.042674 seconds/state-change Fame (Havok 1 Region): Adjusted: 0.006545 seconds/state-change Fortuna (Havok 1 Region): Adjusted: 0.008826 seconds/state-change My conclusion from this is that non-Mono region take approximately 0.007 seconds per state-change, while Mono regions take around 0.0435 seconds per state-change. This is approximately 6 times slower at least. Not as slow as when using empty states to test, but still several times slower.
_____________________
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)
|
|
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
|
08-11-2008 11:49
From: Haravikk Mistral Your script introduces events (timers) so I'm not sure how accurate such a measurement can be. Actually a large part of the switching of states most likely has to do with the registration and removal of event handlers. States with only 'state_entry' and 'state_exit' at most are not likely to be a good test at all. You might try throwing in some handlers like 'timer', 'changed', etc. even if they are never executed and don't do much. |
|
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
|
08-20-2008 06:42
From: Hewee Zetkin Actually a large part of the switching of states most likely has to do with the registration and removal of event handlers. States with only 'state_entry' and 'state_exit' at most are not likely to be a good test at all.
You might try throwing in some handlers like 'timer', 'changed', etc. even if they are never executed and don't do much. The states I want to use in my script only contain state_entry(), and I feel it's a valid use-case (one that I'm concerned about) as it's allowed me to code my parser very efficiently. One thing I'm noticing regarding Mono's memory usage; it's awful! I'm writing another script which uses a lot of function-calls and lists and these are obviously the "extreme" cases that require tons more memory, because I'm finding that adding a relatively short function eats up 3-6kb of memory! 64kb isn't as much extra as it seems, since my script barely fit in LSO-LSL's 16kb of memory, it's barely fitting into Mono's 64kb of memory either  I need about 12kb of free memory in order to manipulate 5 lists each of around 16 integer entries in size. Even allowing for list-overhead in LSO-LSL that's only about 1kb of data tops, allow an extra 400 bytes for overhead in manipulating the lists.
_____________________
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)
|
|
Tyken Hightower
Automagical
Join date: 15 Feb 2006
Posts: 472
|
08-20-2008 09:00
Nevermind, I R dumb.
|
|
Hewee Zetkin
Registered User
Join date: 20 Jul 2006
Posts: 2,702
|
08-20-2008 11:53
From: Haravikk Mistral ...I'm finding that adding a relatively short function eats up 3-6kb of memory! 64kb isn't as much extra as it seems, since my script barely fit in LSO-LSL's 16kb of memory, it's barely fitting into Mono's 64kb of memory either I need about 12kb of free memory in order to manipulate 5 lists each of around 16 integer entries in size. Even allowing for list-overhead in LSO-LSL that's only about 1kb of data tops, allow an extra 400 bytes for overhead in manipulating the lists. In other words Mono is going to discourage breaking code up into discrete and well-manageable units (such as methods to add and manage "structure" instances with records stored in several lists)? Now THAT is something that will concern me greatly. |
|
Strife Onizuka
Moonchild
Join date: 3 Mar 2004
Posts: 5,887
|
08-20-2008 13:15
From: Haravikk Mistral ...I'm finding that adding a relatively short function eats up 3-6kb of memory! I'd love to see the source of that function. It's sounding like you need to optimize your code for size or Mono is doing something strange. /54/c1/88658/1.html
_____________________
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
|
|
Escort DeFarge
Together
Join date: 18 Nov 2004
Posts: 681
|
08-23-2008 14:55
OK more "real world" underwhelm-ment for me... I figure that MONO would be no better (and probably worse for the grid than LSL as pointed out above) but at least we gain all that memory right? So I decided to find out how much/how useful all that new memory would be for data storage... One *really interesting thing* I discovered pretty quickly was that "list voodoo" will no longer increase your storage efficiency over and above a straight list append in any significant way. Storing a record is about 20% *slower* than using LSL list append. Storing a record is about 40% faster than the now-pointless "list voodoo" technique. You can store about 4 times as many records than using plain LSL list append. You can store about 2 times as many records than with the old "list voodoo" technique. Using a simple data storage script that stored various strings as records, I got the following comparative numbers... LSL stores... 55 records in 1677 ms ==> 30.49ms per record LSL using "list voodoo" stores... 121 records (gain of 120%) in 6606 ms ==> 54.60 ms per record MONO stores... 252 records (gain of 458%/208%) in 9454 ms ==> 37.52 ms per record MONO using "list voodoo" stores... 256 records (gain of 465%/212%) in 9024 ms ==> 35.25 ms per record Overall the benefits for in-world script data storage appear to be: 1) Simpler code 2) 40% faster record storage (assuming you were using "list voodoo" previously, 20% *slower* if not) 3) Twice the storage (if used "list voodoo", four times that if not). I'll take it, but it's hardly the revolution I'd been sold/had hoped for. /esc PS this is the simple script i was using for my tests... integer USE_VOODOO;
list stuff;
string type;
string object_title = "This is a test object name that takes up the maximum space all*";
default {
state_entry() {
if (llGetFreeMemory() > 20000) {
type = "MONO";
} else {
type = "LSL";
}
USE_VOODOO = llGetStatus(STATUS_PHANTOM);
if (USE_VOODOO) {
type += " (USE_VOODOO)";
}
llSetText(type + "\nRunning...", <0,1,0>, 1);
float time = llGetTime();
integer count;
if (USE_VOODOO) {
while(llGetFreeMemory() > 1024) {
stuff = (stuff = []) + stuff + llList2CSV([object_title, NULL_KEY, count]);
count++;
llSetText(type + "\nRunning " + (string)count, <0,1,0>, 1);
}
} else {
while(llGetFreeMemory() > 1024) {
stuff += llList2CSV([object_title, NULL_KEY, count]);
count++;
llSetText(type + "\nRunning " + (string)count, <0,1,0>, 1);
}
}
llSetText(type + "\n" + (string)count + " items\n" + (string)(llRound((llGetTime() - time) * 1000)) + "ms", <1,1,1>, 1);
}
} *edited to correct script transcription error
_____________________
http://slurl.com/secondlife/Together
|
