Latest revision as of 17:33, 30 December 2018

MONO v LSO

I noticed this script was written for use with LSO (no mention of that fact though (unless I am missing it)) so I set about writing a version to handle both LSO and MONO. Yet again I find myself pulling faces at the screen whilst trying to make sense of MONO's free memory. I came up with this -

   GetBytes(integer type)
   {
       integer this; // How many bytes are used (minimum) to compile and run.
       if(type == 64) this = 3844; // This amount is hard to reduce in mono
       else this = 354; // Slight changes have big effects in LSO
       llOwnerSay((string)((1024 * type) - (llGetFreeMemory() + this)));
   }
   default
   {
       state_entry()
       {
           GetBytes(16); // 1 simple call per test.
           // Although (in mono) it is very hard to tell exactly how many bytes are used by each call of GetBytes()
           // One thing is for certain...Mono is odd.
           
           // An example of code you might test -
           
           llOwnerSay(llDumpList2String(["is", "how", "much", "does", "this", "code", "take", "up", "in", "bytes?"], " "));
           
           // The llOwnerSay() above takes 512 bytes in mono and 122 in LSO
           
           // When a script is first compiled in mono there is a larger byte count used than after all subsequent resets.
           // On the first run the state_entry llOwnerSay() code takes 572 bytes. After reset 512.
           // LSO does not have this initial discrepancy.
       }
   }

I am sure someone else can do better. What interests me is how we should accurately measure memory use when llGetFreeMemory returns some very odd results (if you play around with enough variants for long enough). I wonder if someone wise might share? -- Fred Gandt ^{(talk|contribs)} 23:57, 25 April 2010 (UTC)

There are a few more clues and links about Mono's memory management, including a possible explanation of the 512-byte change you saw, at this page. Also, this page shows examples of the Mono instructions that the compiler generates for an LSL function call. -- Becky Pippen 18:31, 26 April 2010 (UTC)

I wouldn't say that "Even Mono experts describe Mono's memory management and garbage collection as squirrely and non-deterministic at best, so expect a few puzzling results in Mono." is exactly an "explanation of the 512-byte change" (I didn't see a 512 byte change btw). It would be nice to actually know what was going on but frankly, I am not going to lose any sleep over it. I am far more concerned about how the Script library has many bad scripts or scripts like the original of this that can't be considered up to date or accurately presented. *shrugs* I am very tired though. -- Fred Gandt ^{(talk|contribs)} 20:53, 26 April 2010 (UTC)

@@ Line 1: / Line 1: @@
-= The Plus Four Instrument =
+= MONO v LSO =
-Part of the inspiration for beginning to teach new people how to measure byte code size was the following fragment from [[Talk:Hex]]
+I noticed [[Code Sizer|this script]] was written for use with LSO (no mention of that fact though (unless I am missing it)) so I set about writing a version to handle both LSO and MONO. Yet again I find myself pulling faces at the screen whilst trying to make sense of MONO's free memory. I came up with this -
+    GetBytes(integer type)
-::[... snipped ...]
+    {
+        integer this; // How many bytes are used (minimum) to compile and run.
-::My steps are below:
+        if(type == 64) this = 3844; // This amount is hard to reduce in mono
-::# Compile and execute <code>default{state_entry(){llOwnerSay((string)llGetFreeMemory());}}</code> to establish a baseline
+        else this = 354; // Slight changes have big effects in LSO
-::# Paste an implementation at the top of script from #1, compile and run.
+        llOwnerSay((string)((1024 * type) - (llGetFreeMemory() + this)));
-::# Subtract the result from #2 from the result of #1; you now have the bytecode cost.
+    }
-::# Repeat steps #2 & #3 for each implementation.
+    default
+    {
-:[... snipped ...]
+        state_entry()
+        {
-I call that the "plus four" instrument, since so far as I know, quoting from the [[Code Sizer]] article:
+            GetBytes(16); // 1 simple call per test.
+            // Although (in mono) it is very hard to tell exactly how many bytes are used by each call of GetBytes()
-:Note: Take care to avoid falling into the easy error of printing llGetFreeMemory() before and after you delete the last function of the script. Adding the first function to the script costs an extra 4 bytes. Only people who understand LSO know why, and they haven't yet published that explanation anywhere near here.
+            // One thing is for certain...Mono is odd.
-= Why The [[Code Sizer]] Article Exists =
+            // An example of code you might test -
-The [[LSL Script Efficiency]] article says "Efficiency is how much resource a particular script uses to accomplish a goal".
+            llOwnerSay(llDumpList2String(["is", "how", "much", "does", "this", "code", "take", "up", "in", "bytes?"], " "));
-Yes exactly.
+            // The llOwnerSay() above takes 512 bytes in mono and 122 in LSO
-We should measure not only [[LSL Script Efficiency#How_Fast_Does_That_Code_Run]] but also how small is that code, as is conventional in academic and commercial computer science. When we rewrite code to produce equivalent results more efficiently, we trade brevity and clarity and conventionality and space and time off against one another. LSL can only measure space and time. We should show exactly how to measure both of those, in order to invite more people to make such measurements, to build a consensus science of how to write small and fast LSL code.
+            // When a script is first compiled in mono there is a larger byte count used than after all subsequent resets.
+            // On the first run the state_entry llOwnerSay() code takes 572 bytes. After reset 512.
-LSL gives us [[llGetFreeMemory]] to measure how small is that code, just as LSL gives us [[llGetTimestamp]] to measure how fast does that code run. We the LSL wiki authors have written the [[Code Racer]] and [[Efficiency Tester]] articles to show how to call llGetTimestamp to measure how fast does that code run. Now likewise we should write an article to show how to call llGetFreeMemory to measure how small is that code.
+            // LSO does not have this initial discrepancy.
+        }
-I guess we should publish that article separately. Here it is now.
+    }
+I am sure someone else can do better. What interests me is how we should accurately measure memory use when [[llGetFreeMemory]] returns some very odd results (if you play around with enough variants for long enough). I wonder if someone wise might share? -- '''[[User:Fred_Gandt|Fred Gandt]]''' <sup><small>([[User talk:Fred_Gandt|talk]]|[[Special:Contributions/Fred_Gandt|contribs]])</small></sup> 23:57, 25 April 2010 (UTC)
+: There are a few more clues and links about Mono's memory management, including a possible explanation of the 512-byte change you saw, at [[User:Becky_Pippen/Measure_Script_Memory_Usage|this page]]. Also, [[User:Becky_Pippen/LSL_Performance|this page]] shows examples of the Mono instructions that the compiler generates for an LSL function call.  -- [[User:Becky Pippen|Becky Pippen]] 18:31, 26 April 2010 (UTC)
+::I wouldn't say that "Even Mono experts describe Mono's memory management and garbage collection as squirrely and non-deterministic at best, so expect a few puzzling results in Mono." is exactly an "explanation of the 512-byte change" (I didn't see a 512 byte change btw). It would be nice to actually know what was going on but frankly, I am not going to lose any sleep over it. I am far more concerned about how the Script library has many bad scripts or scripts like the original of this that can't be considered up to date or accurately presented. *shrugs* I am very tired though. -- '''[[User:Fred_Gandt|Fred Gandt]]''' <sup><small>([[User talk:Fred_Gandt|talk]]|[[Special:Contributions/Fred_Gandt|contribs]])</small></sup> 20:53, 26 April 2010 (UTC)

Difference between revisions of "Talk:Code Sizer"

Latest revision as of 17:33, 30 December 2018

MONO v LSO

Navigation menu

Search