Revived JIRA for increase in memory limit

[Wulfie Reanimator]

As usual... No sources or examples for anything. Just more of the same old misinformation and false beliefs. (Comments affect script performance? What even is a compiler? 😂)

Edit: A site as a whole is not a "source." Didn't they teach you that in school? You must link the page where the information is found.

Edited February 21, 2019 by Wulfie Reanimator

[steph Arnott]

2 minutes ago, Wulfie Reanimator said:

As usual... No sources or examples for anything. Just more of the same old misinformation and false beliefs. (Comments affect script performance? What even is a compiler? 😂)

The source is in the SL wiki. It is all there for you to read.

[chibiusa Ling]

I will leave this here : http://wiki.secondlife.com/wiki/LSL_101/Comments,_White-space_and_Formatting

More specifically this bit : "The form of the script that is actually executed (called the compiled version) has all the comments and white space removed, so they don't cause the script to execute any slower, or take up any extra memory."

[steph Arnott]

3 minutes ago, chibiusa Ling said:

I will leave this here : http://wiki.secondlife.com/wiki/LSL_101/Comments,_White-space_and_Formatting

More specifically this bit : "The form of the script that is actually executed (called the compiled version) has all the comments and white space removed, so they don't cause the script to execute any slower, or take up any extra memory."

Well i was not aware of that so thank you for the correction. But there is another page that states it does use bytes.

[Love Zhaoying]

1 minute ago, steph Arnott said:

Well i was not aware of that so thank you for the correction. But there is another page that states it does use bytes.

It would be helpful, if for any claims you make, that you please provide a link to the information. That way, we can all learn from it. Perhaps, the information was old, wrong, misinterpreted, or needs to be updated. Compilers never have preserved comments. This is because they do not result in any code. 

[steph Arnott]

1 minute ago, Love Zhaoying said:

It would be helpful, if for any claims you make, that you please provide a link to the information. That way, we can all learn from it. Perhaps, the information was old, wrong, misinterpreted, or needs to be updated. Compilers never have preserved comments. This is because they do not result in any code. 

The page on Mono states why the scripts are set at 64k.

[Wulfie Reanimator]

I can only assume this is the paragraph Steph is clinging to on the holy page of Mono:

"In some extreme cases Mono scripts can use up to four times the memory as LSL2 scripts. To maintain backwards compatibility, the script size limit has been increased from 16KB to 64KB."

This does not imply that they intended to keep scripts at the original size. They just chose a size that wouldn't break anything while not seeing a reason to go higher at the time. Later on the same page, in the FAQ section, there's even this question:

"64K? Wow, isn't that going to encourage inefficient scripting? 
We hope that the change will promote more efficient scripting. Currently programmers have to get around the 16K limit by using multiple scripts, and a lot of cycles get spent on passing data between those scripts. With a single script that would not be necessary."

Even back then they've recognize the benefit of not having to split one script into multiple. This consideration is still alive as shown by the conversation with a Linden earlier.

[steph Arnott]

3 minutes ago, Wulfie Reanimator said:

I can only assume this is the paragraph Steph is clinging to on the holy page of Mono:

"In some extreme cases Mono scripts can use up to four times the memory as LSL2 scripts. To maintain backwards compatibility, the script size limit has been increased from 16KB to 64KB."

This does not imply that they intended to keep scripts at the original size. They just chose a size that wouldn't break anything while not seeing a reason to go higher at the time. Later on the same page, in the FAQ section, there's even this question:

"64K? Wow, isn't that going to encourage inefficient scripting? 
We hope that the change will promote more efficient scripting. Currently programmers have to get around the 16K limit by using multiple scripts, and a lot of cycles get spent on passing data between those scripts. With a single script that would not be necessary."

Even back then they've recognize the benefit of not having to split one script into multiple. This consideration is still alive as shown by the conversation with a Linden earlier.

No, it implies that due to the extra memory usage with Mono that the target was 32kb. Which i did state.

[Love Zhaoying]

On 2/19/2019 at 8:50 PM, Lucia Nightfire said:

Lindens, please give us a shakes-my-head or facepalm or eye roll emote ASAP.

 

[Gabriele Graves]

3 hours ago, Love Zhaoying said:

 

I'll raise your facepalm to this:

 

Edited February 21, 2019 by Gabriele Graves

[steph Arnott]

6 minutes ago, Gabriele Graves said:

I'll raise your facepalm to this

OMG Trekkies have crossed the void into the this universe.

Edited February 21, 2019 by steph Arnott

[Innula Zenovka]

18 hours ago, steph Arnott said:

No, it implies that due to the extra memory usage with Mono that the target was 32kb. Which i did state.

I'm clearly misunderstanding something, but I can't find anything on the wiki page about Mono that seems to me to suggest that.    All the references to the figure 32 I can find there all relate to the 32 bit configurations of Linux and Windows used for OpenSim tests.

There seems to me to be nothing in the article that suggests anything about what LL's original intentions might have been, other than not to break any existing scripts when they were compiled as Mono.   

Can you please explain where the 32kb figure for their original target comes from?   What makes you say the original target was 32kb rather some other figure, or that they had an initial  target in mind at all?

[steph Arnott]

2 minutes ago, Innula Zenovka said:

I'm clearly misunderstanding something, but I can't find anything on the wiki page about Mono that seems to me to suggest that.    All the references to the figure 32 I can find there all relate to the 32 bit configurations of Linux and Windows used for OpenSim tests.

There seems to me to be nothing in the article that suggests anything about what LL's original intentions might have been, other than not to break any existing scripts when they were compiled as Mono.   

Can you please explain where the 32kb figure for their original target comes from?   What makes you say the original target was 32kb rather some other figure, or that they had an initial  target in mind at all?

If you read it there is part that states Mono uses more memory than LS2. That logically means they had to step to the next level from 16kb to 32kb so they did not break. It then states that under testing a minority used four times the memory which resulted in having to step to 64kb so as not to break them. Therefore the planned limit was 32kb and not 64kb which had to be used. 

[Zodiakos Absolute]

On 2/22/2019 at 3:02 AM, steph Arnott said:

If you read it there is part that states Mono uses more memory than LS2. That logically means they had to step to the next level from 16kb to 32kb so they did not break. It then states that under testing a minority used four times the memory which resulted in having to step to 64kb so as not to break them. Therefore the planned limit was 32kb and not 64kb which had to be used. 

I found a page on wikipedia I think you should read: https://en.wikipedia.org/wiki/Non_sequitur_(fallacy)

[Innula Zenovka]

On 2/22/2019 at 8:02 AM, steph Arnott said:

If you read it there is part that states Mono uses more memory than LS2. That logically means they had to step to the next level from 16kb to 32kb so they did not break. It then states that under testing a minority used four times the memory which resulted in having to step to 64kb so as not to break them. Therefore the planned limit was 32kb and not 64kb which had to be used. 

Sorry for the delay in replying -- I meant to and then First Life became rather busy and I forgot!

Thanks for explaining your reasoning.   I understand now what you mean, but all I can say is that I don't read the section in the same way you do.

I understand the whole article to mean that LL were interested in introducing mono primarily because it runs so much faster on their servers, thus allowing a lot more script actions to take place at the same time without slowing down other operations.    They weren't particularly interested in how much memory the scripts use, since, as the article puts it,

Quote

Mono uses more memory than the typical LSL bytecode. It offsets this by introducing dynamic memory allocation. LSL2 allocates a full 16KB for all scripts, even simple "Hello, Avatar" ones. Mono allocates only the memory it needs. In tests on typical regions it turns out that the combination of Mono using more memory, but allocating memory better, making it far smaller as the overall memory footprint goes.

I don't understand how that works but somehow using Mono means that, while individual scripts use up to four times as much memory as do LSLO ones, because Mono allocates memory more efficiently this means LL can run them using the same memory capacity as LSLO scripts (maybe less, even).   

So my take on the article as a whole is that LL wanted to introduce Mono so they could run more scripts simultaneously without increasing processor capacity.    To ensure nothing broke in the process this meant they had to increase the memory allocation for individual scripts but the question in LL's corporate mind at the time was "how much memory should we allow existing  scripts to have so they don't break when compiled as Mono?" rather than "what's the least amount of memory we can get away with giving them?"   

That is, they were focussed on making the transition to Mono as seamless as possible, and that's all.    But now I do see how you reach the conclusions you do, even though I don't read the article the same way you do. 

Edited February 25, 2019 by Innula Zenovka

[Coffee Pancake]

We're doing this all wrong. This isn't a fact based technical discussion, it's an alternate reality role play.

LSO scripts are faster. Lag is caused by theoretical maximum script memory. Linden Lab have done nothing to the server code for 10 years. The wiki is up to date and well edited. The SL guide book advised us to get jobs as strippers .. wait .. 😂