Mono and memory gains? or not really?

Will the mono memory gains be a case of Linden Labs "takething" away what Linden Labs hath given?

From: https://wiki.secondlife.com/wiki/Mono:
" The Mono server changes are checked in for the 1.24 server. ... The plan is for the Mono server to roll out to the main grid the week of 10 August. The Mono viewer changes are checked in for the 1.21 viewer, which should go to release candidate on 20 August. ......

Mono uses more memory than the typical LSL bytecode. ..... In some extreme cases Mono scripts can use up to 4 times the memory as LSL2 scripts. In order to maintain backwards compatibility the script size limit has been increased from 16K to 64K."

Hrm. Does anyone know if this means the following bad news, to those who were waiting for "4 times the memory" in scripts:

Does it mean that if you have a script currently using 14k of memory, after mono, instead of having the hoped-for roughly (64 - 14 = 50k) of memory free gain, you will instead see your script go from using 14k of memory to (14 x 4 = 56k) of memory, wiping out any gains?

(Though I note the writer quoted above gives the proviso that the quadrupling can happen in "*extreme cases*", one might wonder what happens in less extreme cases? mere tripling?)

It won't be 4 times. But from my experiences, it will be 2 to 3 times. Which is still very, very sweet. I think LL was just being ultra-conservative in their wording, to prevent false hopes in case it didn't work out. But It is a significant gain in memory.

I think for most scripting applications, you can consider as though the memory limit has actually been raised to 64KB. However, I wouldn't actually fill all of that up with bytecode, of course. You always have to leave plenty of room for the memory you end up using at runtime.

What are the extreme cases? Do we have figures on memory usage of different things like function calls etc.?

The extreme reference:

https://wiki.secondlife.com/w/index.php?title=Mono&oldid=82713#Mono_benefits

was added today, 4 August 2008 at 18:56 by Periapse Linden (formerly Periapse Seattle.) You'd need to ask him what he meant, I guess, or else we'd just be guessing.


[/url]

How do we compile mono scripts in those 10 days between the 1.24 server and the 1.21 client?

Will the mono beta viewer work on the main grid?

You won't.

No.

http://www.secondscripter.com

According to the cited source you can force the beta viewer to connect to the main grid. I'm pretty sure I've succeed in doing the opposite, so I can believe it's possible with the right combination of command line options.

In my initial posting, I provided the link to the full information.

This link: https://wiki.secondlife.com/wiki/Mono

You forced the entire main grid to connect to your beta viewer?

LOL. Why yes. Bow down before my might.

"The Mono viewer changes are checked in for the 1.21 viewer, which should go to release candidate on 20 August. The viewer changes include a checkbox on the script edit dialog (which allows you to make a script compile to Mono), a Tools menu item to allow you to recompile to Mono all the scripts in your selection,"

from https://wiki.secondlife.com/wiki/Mono

So I wonder if that's why they kept "Tools -- Recompile scripts in Selection" around as a dead item on the menu for almost two years?

OK my 2L$ worth (not that its worth mutch)

I understand that Hewee is so well connected he rules the grid

Let us take the worst case, a script that used 16k is now 4 times the size and uses 64k
no change, except it will execute faster.

However all scripts break up into two parts, code and data, the code may take four times the byte-count but I can't beliveive the data does (someone tell me if I'm wrong), no way does an integer suddenly take 128bits. So iI think there must be an overall gain, after all how many scripts use 16k without holding any data.

There may be differences in memory overhead for lists, for example. But you're right, an integer that takes 128 bytes would be kinda funny. Which gets back to Haravikk's question:

And to answer that, one would need to approach Periapse Linden, who made the "extreme cases" comment.

Me, I'll just wait and see, cause I guess knowing in advance ain't going to change what's coming one way or the other.

True.

I need to get off my butt and test a bunch of stuff under MONO, I've needed to do that for a while but have been working on other stuff.

I'm trying to get measurements for memory use under Mono, however either the allocation of memory is really screwy or llGetFreeMemory() does not work properly, as I'm getting VERY varied results.

For example, declaring an empty list apparently requires 104 bytes, fine assuming that's all overhead for making it work properly. Creating a list with ZERO_ROTATION in it requires an extra 32-bytes, not great but it's kind of expected; lists are crap after all.
Create a list with TWO ZERO_ROTATIONs in it and it takes up over 500 bytes. Something is not right there!

Some things also do not appear to cost anything, which I also do not understand! It doesn't seem possible to measure the cost of anything anymore =(

I had an old thread here with what looked like a memory leak bug with lists in the LSL VM, not sure if something similar exists with Mono.

Also, AFAIK the Mono memory allocation is dynamic, and I wouldn't be surprised if it goes up and down in blocks, so the 500 byte increase might be because your script bumped up to needing one more memory block, and the GetFreeMemory is looking at "number of blocks used". The "no cost to some operations" might be due to the same thing - the memory required was available in the current block.

Or something like that.

Yes you can use the beta viewer on the main grid. I"ve already been doing it.

And no, you don't have to use the beta viewer to *use* Mono scripts. Only to *compile* Mono scripts.

A couple of "real life" examples from recompiling -
100 line script was 12k free in mono leaves 50k free
500 line script was 4k free in mono leaves 25k free

YMMV!

I had hoped that > 2000 line scripts would be possible but it seems it's not going to be quite as good as it sounded.

/esc