Babbage Linden - Limit scripts PER PARCEL

The average sim doesn't require memory limits to avoid thrashing, either, it's only exceptional circumstances that lead to this problem... so looking at *average* script usage isn't going to tell you where the problem is... it's *exceptional* script usage that's the problem.

And the average size of mono scripts is increasing, as people take more advantage of it and as people simply recompile scripts as mono just because they "know" it's better.
The Mono project predated the Mono rollout by at least a year.

Try three years. And the whole point of the exercise was to get them more flexibility and better memory management. It's basically that Mono enables this limits thing, it's not the cause of it.

Let's not forget that most usages of multiple scripts are just to get around the forced delays the Lindens themselves artificially impose!

Give us llSetPrimitiveParamsLink with no sleep and the 200 prim hair needs only one script.

Or how about in-script multithreading or proper libraries?

Ah, that's why all the presentations and promotions have been about performance, performance, performance, cool fractals, and performance.

Mono is not a requirement for anything they're doing now. Mono makes it harder and more complex to limit script memory and CPU usage.

Some arrogant jumped up twit said :

'Good scripters should welcome these changes....incompetent scripters should rightly fear them, for they will be exposed for the charlatans that they are.'


I haven't learned to use scripts yet - I merely bung in a door script in here or a particle script there changing the numbers until they work. And if they work as far as Im concerned I worked using the tools as provided by lindens and people who wrote the scripts before me.....

How I tire of so called experts arguing among themselves while others have a go at dispporoving them.

We're using the tools and materials lindens laid down and if they work - great. Don't you go pulling your jumped up snooty name calling on anyone....

Those make good videos, memory makes a boring movie.



That was in 2005.


If it was so easy to fix LSO, Cory wouldn't have hired somebody to replace it.

And every time they come up with these figures the numbers are bigger. 7k, then 9k, then 11k.

They could have added a checkbex on the LSO compiler to allocate 4k, 8k, or 16k for the script (which is basically what they are now saying they're going to put in for Mono, except it'll be 8k, 16k, on up to 64k) and 90% of the LSO scripts would have been able to run under 4k.

It wouldn't have taken 3 years to fix in LSO. I could have done it in less time than that. I *HAVE* done comparable kinds of work on real-time interpreters in less time than that. But it wouldn't have been fast enough to run Mandelbrot sets in real time.

If it was *just* a matter of memory management and scheduling, it wouldn't have been necessary. Performance was always the driver for the Mono conversion. And I'm not saying that performance is a bad thing, I'm just saying that the advantages of Mono are way overstated... to the point where they're spinning workaround for *disadvantages* of Mono as advantages.

Performance was one driver, memory was another, a way to get away from a dog of an interpreter locked into a dog of a language was yet another. Sure, they could have slapped on a few band aids and called it a day, but there would still be the attendant dependency hunts and multiple binary formats and bugs, all nice and happy until the next problem showed up. CIL got them something that already met those wishes, and it got done in way less than the chronological time (it was all put on hold for a couple of years there).

And of course, the thrashing issues with void sims were apparent months before Mono went live. Content wasn't limiting itself to 16K. In the contents of a popular pre-Mono bed from a maker probably better known for courtroom adventures than products at this point, there are 41 scripts (1 controller and 40 workers) for storage alone, plus 9 more scripts (4 of those 9 are permissions holders for the 4 pose balls so not much to be done about that), and that's before any pose balls are rezzed. That's 784K for one idle object, good old fashioned LSO.

Perhaps there is some confusion about the scheduler bug vs. the limits? Those are separate things.

Which comes down to performance. And I'm not saying that's not adequate justification. I'm saying that MEMORY IS NOT. Because setting a less aggressive version of the optional per-script quotas they're proposing for Mono would have cut the real memory use of LSO scripts even more than it will for Mono.

The first real-time interpreter I worked with had a total of 16k, for everything on the system, including multiuser development. And in production 12k of that 16k was ROM... you only got 4k for data, for ALL your threads. You can do a lot in 4k.

What do you think the purpose of these "artificial" delays is? Give that some careful thought, and note that virtually all of these functions use a lot more sim resources than merely running LSL code and computing values.
The 200 scripts is more due to lack of llGetPrimitiveParams, which is another story. I disagree with LL's arguments for not implementing it.
I don't think multithreading is necessary or appropriate for LSL. There's a lot to be said for the simplicity of the language.

Libraries you can do externally. It sure would be nice to have them inworld, but it wouldn't improve script efficiency or affect any of the issues we're discussing here.

Unfortunately, you have to be an estate manager on a private estate to see script runtime usage, and there's currently no way to see script memory usage.

LL are planning to roll out the ability to see script memory for parcel owners, which will be a great thing. I hope that in the process they can add the abilitty to show script runtimes as well.

IMHO, more than half the problem would be solved just by giving more folks the tools to see these measurements.

If things go according to plan, as part of this whole "memory limits" initiative we expect some better tools for seeing what scripts are consuming what memory and what processing resources, even on Mainland parcels.

Right now, though... not much you can do, really. If you have the source code for the scripts, you might be able to get some useful info out of llGetFreeMemory(), although it's tricky to interpret.

If one wanted to prepare for memory limits well in advance, one might do a very coarse-grained script audit: just counting which objects have how many scripts. If they're mod-perm, it may be worth checking to see which scripts are actually in the Running state. One could also look at scripts left around that aren't doing anything anymore, such as texture animation scripts in water prims, or particle effects that never change; those may be worth disabling or removing.

I suppose it would be prudent to be a little cautious about buying new scripted items until this all sorts out. For example, I wouldn't rush out to buy a texture organizer with a gazillion memory scripts inside. Probably the same with networked vendors, although one supposes the big names will issue memory-conserving updates before it becomes a critical problem.

(Dumb question for the VM-acquainted folks here: If a script is set to the not running state, do we think it still counts against memory limits? It seems like it would still be memory resident on the sim, just not scheduled... but if it were paged out, nobody would care until it was set to run again. But still... if it's in a rezzed object but doesn't count against memory limits, how would those limits be enforced when another script wakes it up?)

Its not about reducing scripts, its about distributing their use more equitably. I work my butt off to keep scripts lowered in Hollywood Airport (Santa Barbara Sim) so that planes can operate smoothly, then a couple ladies walk in with high prim scripted hair and Mystitools on. BAM, so much for my efforts to keep the sim running smoothly.

My suggestion is to carry on as planned. Stop individual hoarding of sim resources. YAAAH LL on this one.

But you don't have to be an estate manager or private estate owners to see how much your avatar rendering costs (ARC) are (a different but still valuable measurement).

Go to ADVANCED --> RENDERING --> INFO DISPLAYS --> AVATAR RENDERING COSTS.

You will be amazed at what high prim hair will do to your ARC

ARC is pretty much pointless. Doesn't really deal with server-side lag causes, such as scripts, and it doesn't really do a good job of calculating client-side rendering lag anyways since it doesn't take texture size into account, among other things.

Unfortunately, all that ARC seems to accomplish, in practice, is convincing people that they're "low lag" if they have a low ARC score, even though they may be wearing all kinds of resource-hogging scripts.

A naked avatar with no prims attached SHOULD have an ARC of about 6000, based on the overhead of rendering the avatar mesh... the avatar mesh is EXPENSIVE. It's got an ARC of 1.
Might increase your real ARC by 50%, and has no effect at all on the sim.

I think it would probably be more confusing if 6000 was the lowest ARC you could get...

Not that I think the current implementation is without bugs, just that starting at 1 is less confusing than starting at 6000.

Sure. Facts are often confusing, because they're complex. People have to understand facts to actually make use of them. And they do. People can understand 0C, 32F, and 273K. They can understand 6000 ARC.

Start at 100 and divide all values by 60.

But doesn't it have an effect on how long it takes people to rez? That's a very real perception of lag -- not just how quickly or smoothly you can move. I see people with Damselfly hair and lots of jewelry with ARCs of over 10000. That has to be doing something to my ability to see SL right? (BTW, they take off the hair and the ARC drops by 6000.)

That's a different kind of lag and nothing to do with scripts (see thread title).

Not as much as you'd think. The difference between one avatar with an ARC over 10,000 and two avatars with ARCs of 2,000 isn't that much.

Thank you for this information. If I could see such usage the way I can see prims, I would control them for my own good.

BT

omg..what a difference a few minutes makes...activated ARC and i was about 5000....took off hair and was 800....went shopping got new hair equally effective 1352...........

BUT saw a woman that was 135758 can this be a record? and she wasnt that flashy either...

You can have a huge ARC and cause no lag at all, and a low ARC and be very laggy. It's a very rough guide at best.