What seems to be an issue is a non-understanding of what a VM is. I use the analogy of a glass of water. If your LSL scripts are hydrogen and oxygen, then the compiler is what combines them to H2O (water), and the VM is the glass that holds the water.

Using that analogy, it becomes rather clear that the VM is a very fundamental piece that needs to be replaced. In the current setup, it seems to be the equivalent of putting too much water in the glass on occassion (causing lag), and the cup has holes Linden Labs keeps taping over. The problem is that then you end up losing water.

By replacing the cup with a larger, more solid one, we will be able to have more water in there, less holes, and everything runs smoother. This translates real-world to cpu utilization, memory usage, etc. While I’m sure it cannot guarantee better stability, it will go a long way into allowing for it. It is actually a much deeper and more foundational change than most people realize, unless you are a software developer.

Now, doing something this profound has to be done extremely carefully and methodically. I’m not sure how the testing is being done, but 100% compatibility with the current LSL VM is an impressive, and difficult task. This needs to be done first, above all else. After a port, only then can one focus on additional features, like other languages, extensions to current LSL, etc.

I, as a dev, am not necessarily in love with LSL and its very odd quirks, but I understand fully the methodical approach needed to this effort.

Just from observation of the system and the behavior, I however would hazard a guess that Havok4 + Mono is going to improve stability tremendously; probably also allow for code and design changes in the system to allow increased grid stability. My gut tells me a lot of this is needed to help out the transaction and asset server issues, too. In an interdependent system, one problem can manifest in other ways… especially one as complex as SL.

I wish you guys in LL luck, you’ve bitten off one heck of a project.

“…PAYS the lab for that by premium fee he has the bloody right to have these 100 scripted vendors run as they are supposed to run withot causing any trouble.”
Tell me, where exactly does it say you have the right to have your content run at 100% efficiency? It’s certainly not explicit and I doubt it’s even implied. A lot of the latency I’ve seen is due to poor programming practises by morons. Sure, some things have to be done by polling (Such as certain combat meters and animation overriders) and I agree that such things should be redesigned. It’s common sense that resources aren’t unlimited. Get over it, this is Second Life not Imagination Universe where scarcity doesn’t exist.

“Either LL changes the specifications (system) or LL makes the system capable to run the scripts and all”
Why do you think they are implementing Mono? Because they’re bored? Have you even used Mono on the beta grid?

“Everything else is only apologism.”
Yes, because the world is black and white isn’t it?

If you’re unable to understand the fact upgrading a system to handle new conditions may require a rewrite or introduction of a new subsystem, then your an imbecile who needs to go spend some time in the real world of ICT.

Like I said before: LL set up the system as it is, therefore LL is responsible for keeping this system running. The users are NOT to blame in any way. And if someone decides to set up 100 scripted vendors (which is legal) and PAYS the lab for that by premium fee he has the bloody right to have these 100 scripted vendors run as they are supposed to run withot causing any trouble.

Once again: Either LL changes the specifications (system) or LL makes the system capable to run the scripts and all, as they promise by advertisement.

Everything else is only apologism.

On the subject of script performance, I would love to be able to get performance stats on scripts in my parcel, the way estate owners can get them for their regions.

It’s handy to measure the usage with more than 100% to get a grip on how much more CPU time would be needed to let all scripts run at their expected speed.

(And I didn’t mention a lag meter on objects but that’s just a minor point.)

I do think parts of what your saying IE a lag meter on objects or some way to see what lag is like on objects/scripts is good but limiting people is problematic… The point i was trying to make before …. Was this… people can stop most sim instability caused by lag already if they have an island or are on the mainland it doesnt really matter if they are in fact careful. The main problem is the people writing the scripts need to stress test it or beta test their products in enviroments that are going to be laggy or have alot of people in them.

That would help alleviate things i assure you. Then if the person didnt test it and someone bought an object with the script in it or the script itself and put it in an object and t hen placed it out in an area they are in and they start seeing the sim become unstable IE sim FPS dipping down etc….. They should kindly remove it….. The only thing is this puts all the faith on the people….

They need to be willing to change and try to make SL nicer themselves. I’d rather that then have something forced on me. I dont see avatars as a direct problem unless they are purposly trying to grief….. I’ve not seen many scripts avatars wear that actually caused instability (the lights some wear are aggravating though lol when the ground is bleached >.<) I have however seen lil temp on rezzers sitting around sims causing server lag in a previously stable sim when only one person was in it…..

Like i said before the problem isnt so much the system as the people who misuse it or use it in a careless manner and dont take lag factors into accounts when making a script or building something… Also keep in mind most sims are stable… Though my computers isnt the grandest i can run SL without seeing many places that are unstable… I’ve been to a few places that were but they had tons of scripted vendors out plus a ton of avatars and well the vendors already were putting stress on the area probably so add people into the equations its bad…. I’ve seen shops with lots of non scripted vendors laid out nicely that have minimal lag with a bunch of people…

I guess my point is this all comes down to design on the peoples end…

If you think of the execution of the scripts as customers waiting in line to get serviced, with each script as a customer, it’s easier to understand how you can use 101%, or more, of the resources.

Since every customer hurries back to the end of the line after getting serviced you get a minimum time needed to service everybody in the line before the same customer is back to be serviced and when that time can’t be met, you’re pushing the required usage over 100%. That’s when you get scripts waiting longer than expected for their turn to run and you as a user see this as lag.

On the implementation level, you can do several things to affect how to handle this situation but since the server is closed code, it’s hard to do much more than guess and point at standard solutions.

Since LindenLab has added sleep time for some script functions, they’ve already made some effort to not let a single script use more resources than it should but there is a limit where these delays aren’t enough. And that limit is reached simply by adding more scripts waiting for their turn to run.

Running the scripts in a multi threaded or single threaded environment also makes a big difference in both implementation and expected behavior. Scheduling of execution is tricky to say the least.