Content Creation/Scripting User Group/Transcripts/2011 07 25
List of Speakers
| Acheron Gloom |
| flexi campfire |
| Leonel Iceghost |
| Liisa Runo |
| NeoBokrug Elytis |
Transcript
[08:58] Acheron Gloom: Heya Kelly
[08:58] Kallista Arliss (kallista.destiny): Lail Kelly
[08:58] Kaluura (kaluura.boa): Hi!
[08:59] Kallista Arliss (kallista.destiny): Hail*
[08:59] tehKellz (kelly.linden): good morning
[08:59] !< Sofa: Click the seat to change your animation or position.
[08:59] Nal (nalates.urriah): Morning
[09:00] Ima Mechanique (nielarcher): good afternoon ;-)
[09:00] Kaluura (kaluura.boa): Evening...
[09:00] Liisa Runo: hi everybody
[09:01] Kaluura (kaluura.boa): So... News about the Script Maintenance Project?
[09:02] tehKellz (kelly.linden): Found a couple of bugs on aditi that I fixed on Friday. Depending on how the rest of testing goes it is *possible* it could get an RC this week, but it would be a stretch I think.
[09:04] tehKellz (kelly.linden): Well, we should get started I suppose. :)
[09:04] tehKellz (kelly.linden): News first.
[09:05] tehKellz (kelly.linden): The Magnum RC has been looking really good performance wise.
[09:05] Kallista Arliss (kallista.destiny): Yes, only the diehard 'the system is lagging' people have been complining.
[09:06] Kallista Arliss (kallista.destiny): The people who cry lag when fps drops below 44.9
[09:06] tehKellz (kelly.linden): I shared this graph on Friday, I think. I have a couple more data points today but it looks pretty much the same.
[09:06] Acheron Gloom: Would you be able to throw me a copy of the texture, Kelly?
[09:07] Acheron Gloom: Thanks.
[09:09] tehKellz (kelly.linden): I *think* that the fixes on Magnum are up for promotion this week, though we havn't yet reviewed data from the weekend.
[09:09] Kallista Arliss (kallista.destiny): So the over agressive caching id produce better perormance
[09:11] tehKellz (kelly.linden): The difference there is in the range of 0.05 - 0.1 SimFPS, so maybe a touch for some regions.
[09:12] tehKellz (kelly.linden): To be clear for everyone, I believe Kallista is referring to that 2days fix w/ crasher, where the crash was caused by overly aggressive caching of some data.
[09:12] tehKellz (kelly.linden): And how those points are slightly higher than the 'new fix, no crasher' point.
[09:13] Kallista Arliss (kallista.destiny): the twp orange dits at the tip
[09:13] Acheron Gloom: Ah
[09:13] tehKellz (kelly.linden): Yes.
[09:13] Kallista Arliss (kallista.destiny): which show that you were on the right track
[09:13] tehKellz (kelly.linden): The dataset is really small as well, which can cloud things.
[09:14] Kallista Arliss (kallista.destiny): Welome OO
[09:15] tehKellz (kelly.linden): Next news is the Scripting Maintenance project which is on Aditi as DRTSIM-72
[09:16] tehKellz (kelly.linden): I've run through the features before but briefly: SET_POS_LOCAL, link version of sit target and camera related functions, http-in can return html (with restrictions), you can set a lower memory ceiling on mono scripts and more.
[09:16] Kaluura (kaluura.boa): (Lot of good things in there...)
[09:17] tehKellz (kelly.linden): It had some bugs on aditi last week, and the release pipe may be a tad full so I'm not quite sure when it will get to an RC.
[09:18] Leonel Iceghost: is memory ceiling going to help sim performance in any way?
[09:18] Kaluura (kaluura.boa): It should...
[09:19] tehKellz (kelly.linden): Right now, no.
[09:20] Ima Mechanique (nielarcher): does ceiling report correctly for object script memory?
[09:20] Ima Mechanique (nielarcher): or is it still 64KB?
[09:21] tehKellz (kelly.linden): If you set a mono script to a ceiling of 10k then it will stack-heap when you go past 10k total memory used (including assembly) and it will report 10k in all memory reporting tools
[09:21] tehKellz (kelly.linden): It will not report 64KB
[09:22] Ima Mechanique (nielarcher): excellent
[09:22] Ima Mechanique (nielarcher): a step towards getting people to be more efficient ;-)
[09:22] Leonel Iceghost: any plans to make a script able to restart a crashed script?
[09:22] tehKellz (kelly.linden): That is trickier than I would like. I have looked at it in the past.
[09:23] Leonel Iceghost: really? how does the viewer restart it
[09:23] Kaluura (kaluura.boa): Yeah... If we do it easily with the viewer... why not by script?
[09:23] tehKellz (kelly.linden): magic, at least it seems that way sometimes.
[09:23] Leonel Iceghost: lol cool
[09:24] Acheron Gloom: haha
[09:24] tehKellz (kelly.linden): it has to do with the state of the scripting system when a script is running vs. when we are processing messages from viewers
[09:25] tehKellz (kelly.linden): In the latter case it is easy to move things around completely and get things running, in the former it is a bit of a trick.
[09:25] Liisa Runo: scripts being able to restart crashed scripts can also become a problem, some people might just reset the crashed script instead of actually fixing the bug that cause the crash
[09:25] tehKellz (kelly.linden): There is a jira for it, I'm sure I've seen it.
[09:25] tehKellz (kelly.linden): We should make sure it is in the SCR project if it isn't.
[09:25] Leonel Iceghost: Liisa, at least to recover stack head collisions
[09:26] Ima Mechanique (nielarcher): Kelly, is there any docs on what's in DRTSIM-72?
[09:26] Liisa Runo: and what cause the collision if not bug?
[09:26] tehKellz (kelly.linden): I wonder if a script property 'reset on stack/heap' would be more efficient.
[09:26] tehKellz (kelly.linden): though then that is even worse for the case liisa mentions. possible constant crash loop
[09:27] Acheron Gloom: Somewhat off-topic, but does the llGetObjectDetails for script time return the same as the EM panel does now?
[09:27] Ima Mechanique (nielarcher): thanks Kaluura
[09:27] tehKellz (kelly.linden): Acheron yes.
[09:28] tehKellz (kelly.linden): os Avg/frame over the last 30 minutes or life of the object, whichever is shorter.
[09:28] Leonel Iceghost: it still triggers an error in debug channel, if the script has a bug everyone will notice it
[09:29] tehKellz (kelly.linden): True.
[09:29] Liisa Runo: nope, many ppl will not notice it : because of this NON-viewer bug: https://jira.secondlife.com/browse/VWR-26016
[09:29] flexi campfire: [#VWR-26016] Script error particle not displaying above agent when script error comes from a HUD
[09:29] tehKellz (kelly.linden): Though I kinda am starting to think showing script errors for objects you don't own is not that useful most times.
[09:29] tehKellz (kelly.linden): That is just for huds though?
[09:29] Kaluura (kaluura.boa): Not really...
[09:30] tehKellz (kelly.linden): All right.
[09:30] Liisa Runo: it is usefull in some cases, mmaybe it should have a toggle
[09:30] tehKellz (kelly.linden): Yeah. probably better as a viewer side filter / option.
[09:31] Acheron Gloom: I agree to that, Kelly.
[09:31] tehKellz (kelly.linden): It is open discussion day and I'm out of news. Floor is open.
[09:31] Acheron Gloom: If you don't have another point to move onto, can you give a little bit of information about any other changes to script time measurement? As I think there were some. For example I've noticed the measurement of firing guns being at least double what they used to be, and sometimes way higher than double.
[09:31] Acheron Gloom: :3
[09:32] Acheron Gloom: I was waiting to say that.
[09:32] tehKellz (kelly.linden): Sure.
[09:32] Liisa Runo: but what ever path we take, we must make sure that ppl cannot ignore their own errors, we dont want bugged stuff wasting resources get more popular
[09:32] tehKellz (kelly.linden): We are talking about the time reported to EMs in the region/estate debug top scripts panel?
[09:32] tehKellz (kelly.linden): I agree Liisa
[09:33] tehKellz (kelly.linden): So the previous times reported were broken. Flat broken. It is hard to convey how broken.
[09:34] tehKellz (kelly.linden): There were many, many little bugs and some straight up faulty logic.
[09:34] tehKellz (kelly.linden): We were attempting to track an average time used with a single float.
[09:34] Kallista Arliss (kallista.destiny): nit just broken but BROKEN?
[09:34] tehKellz (kelly.linden): The old times reported were BROKEN.
[09:35] tehKellz (kelly.linden): So every time a script ran we would do: avg = avg * 0.8 + time_run * 0.2; This is a bad attempt at keeping 5 run times as average.
[09:36] tehKellz (kelly.linden): Sometimes we would reset to 0, sometimes we would just do avg *= 0.8.
[09:36] tehKellz (kelly.linden): And many times we would just do nothing to the number even if we should.
[09:36] tehKellz (kelly.linden): The end result was a number that was only meaningful in relation to the other numbers, and even then barely due to the other bugs.
[09:37] Kallista Arliss (kallista.destiny): bork bork bork
[09:37] tehKellz (kelly.linden): It was possible for a script to accidentally get a really high or really low number and be poisoned for a long time
[09:37] tehKellz (kelly.linden): So we ripped out that system. It is gone.
[09:40] Qie (qie.niangao): (when ready for a totally ifferent topic) ... It seems wrong for Mesh to be elevating prim equivalence because an object contains a script, when in fact *every* object containing a script (mesh or not) has the same effect on the sim. Really, scripts need to be a separately metered resource, not confounded with prim count. So then, whenever scripts do get metered, the Mesh special case will need backing-out.
[09:40] tehKellz (kelly.linden): Now we track # frames and total run time for ~30 mins. We do some fudging with buckets to keep a rolling average. And we filled in the gaps missing in the old system.
[09:40] tehKellz (kelly.linden): In particular there was a case where the overhead of an idle script was ignored because we did a 'return' instead of a 'break' in a loop - where the only thing after the loop was time tracking.
[09:41] Kallista Arliss (kallista.destiny): oO
[09:41] tehKellz (kelly.linden): So now it looks like idle scripts got a spike in time. I depated this a bit since it would be easy to re-add the old bug and make idle scripts appear timeless as they had before.
[09:41] tehKellz (kelly.linden): But that isn't accurate or true and never was. It was just a timing bug.
[09:42] tehKellz (kelly.linden): or rather, a bug in the timing stats.
[09:42] Acheron Gloom nods
[09:42] tehKellz (kelly.linden): There were other bugs as well, but that was probably the most noticed.
[09:42] Acheron Gloom: Yeah, I've definitely noticed some odd things myself. Like in something that runs an event every 0.05 seconds (timer or control, maybe), if you slept half of that time the script time would be /a lot/ lower than if you didn't sleep.
[09:43] Acheron Gloom: Even though, you would think that the sleep wouldn't make a difference either way really.
[09:43] Kallista Arliss (kallista.destiny): But shouldnl ilde scripts be timeless , in an event dirven system no events should = no time
[09:43] tehKellz (kelly.linden): If a script is sleeping it is using much less sim time than if it is just idle.
[09:43] Acheron Gloom: Well, even enough to drop from say 0.02 to 0.001 or something for the object?
[09:43] Leonel Iceghost: Kelly, you need to call the scheduller after every script event, and external events.. it is insane to put it in a loop
[09:44] tehKellz (kelly.linden): Kallista: while LSL is event driven, the system that runs it is not as event driven, and all scripts are considered active and checked for pending events to add to their queues based on the handlers in the script.
[09:46] Kallista Arliss (kallista.destiny): Even if there are no events of the type for which it has handlers?
[09:46] Acheron Gloom: After everything else is said (just kinda raising my hand here), I also was wondering about lowering our scripts memory limit some more. I believe you said that it wouldn't increase sim-performance to do so at the moment, but I assume it will in the future then? Would it be a large difference?
[09:47] tehKellz (kelly.linden): Kallista: in that case the check is as quick as comparing 2 integers with bitwise &.
[09:48] Kaluura (kaluura.boa): No much room for improvement in here...
[09:48] Kaluura (kaluura.boa): Not*
[09:48] Kallista Arliss (kallista.destiny): Well somewheres there is 2 µsec per script of overhead
[09:48] tehKellz (kelly.linden): 2usec is very small.
[09:50] tehKellz (kelly.linden): Ok, lets switch topics.
[09:50] Leonel Iceghost: if a script has a timer in the next 60 min, it should put itself in the queue and don't waste ony single cycle more.. and then you call the scheduler again when there is a collision with the object, or chat, or user imput..
[09:50] Leonel Iceghost: that way if the script is doing nothing it will be trully there idle just using memory
[09:52] tehKellz (kelly.linden): Qie: In a large sense you are correct. For now what we have is 'PrimEquivalence' which mashes all the resources into a single number. If we pull scripts out to their own resource in some way then we can remove the script effect on the simulation cost.
[09:52] Qie (qie.niangao): okay, as long as you're comfortable with that. just wanted to be sure you'd been consulted.
[09:52] tehKellz (kelly.linden): That would have a cost-lowering effect which is easy to do in the future, on the other hand a cost raising effect (such as adding script cost later) is much more difficult.
[09:52] tehKellz (kelly.linden): I think I wrote both the equation and the code to implement it Qie.
[09:53] Qie (qie.niangao): cool.
[09:53] Acheron Gloom: Haha
[09:53] Ima Mechanique (nielarcher): adding it is easy, getting people to accept it is another story ;-)
[09:53] Kallista Arliss (kallista.destiny): That is indeed 'In the loop'
[09:55] tehKellz (kelly.linden): The benefit of lowering the memory limit on scripts is truth in reporting. Because mono scripts can use up-to their cap if we limit memory on a non-per-script scale (per parcel, per region, etc) then we have to use their ceiling.
[09:55] Acheron Gloom: Ah
[09:55] tehKellz (kelly.linden): If we do that and even a door script uses 64k in mono no one will use mono.
[09:56] Acheron Gloom nods, "That makes sense."
[09:56] Acheron Gloom: this will report correctly for llGetObjectDetails, too, right?
[09:56] tehKellz (kelly.linden): Yes
[09:56] Acheron Gloom: Great to hear.
[09:56] Ima Mechanique (nielarcher): is there a minimum ceiling for mono scripts?
[09:56] Kallista Arliss (kallista.destiny): There are regions that have script+momory counters at the entry point, the spam or even eject prople with too many sctipts/much memory
[09:56] tehKellz (kelly.linden): the minimum is the size of the script at the time the function is called.
[09:57] tehKellz (kelly.linden): (which is just a convenience so you don't immediately crash your own script. Use 1/0 if you need that.)
[09:57] Ima Mechanique (nielarcher): hmm, let me rephrase that. CAn you request the size to the byte or is it blocks? i.e. 128 byte increments?
[09:57] tehKellz (kelly.linden): The resolution is down to the byte.
[09:57] NeoBokrug Elytis: I know you're busy with other projects currently, just wanted to get this question in. Probably been asked a thousand times -- but any chances for a new type: arrays? :3
[09:57] Kallista Arliss (kallista.destiny): Ima, I've heard 4K as an absoult minmum
[09:58] tehKellz (kelly.linden): There is almost no chance of arrays in LSL.
[09:58] Ima Mechanique (nielarcher): great. I have plenty I can shrink
[09:58] tehKellz (kelly.linden): Hello World takes just under 4k.
[09:58] Ima Mechanique (nielarcher): okay. good to know
[09:58] Acheron Gloom: So uh, any chance of an llRezObjectFast with a one-frame delay, and just more aggerssive throttling :3?
[09:58] Acheron Gloom: I doubt it, but *shrugs*.
[09:59] tehKellz (kelly.linden): I haven't seen a jira for that suggestion yet Acheron.
[09:59] Acheron Gloom: I'll make one then.
[09:59] Acheron Gloom: I just figured it wouldn't be liked.
[10:00] Acheron Gloom: Function delays are in frames right, pretty much?
[10:01] tehKellz (kelly.linden): <shrug> the idea of not sleeping scripts with function calls is liked. If we can find a throttle that would work and still allow it to be useful it is a possibility. I'd also like to strip the engergy component from it.
[10:01] Acheron Gloom: Since I assume it worsk the same as llSleep, and I believe llSleep can only sleep to the nearest frame
[10:01] tehKellz (kelly.linden): function delays are in seconds.
[10:01] tehKellz (kelly.linden): A sleep is at a minimum a frame
[10:01] Acheron Gloom: hmm
[10:01] Acheron Gloom: is it precise/accurate though?
[10:02] Acheron Gloom: so a 0.03 sleep would actually sleep 0.03 instead of 0.022 (1 frame) or 0.044
[10:02] tehKellz (kelly.linden): This goes back to the scheduling. When your script next gets checked to run, if it is past the set time it will run.
[10:02] Nal (nalates.urriah): Does that min change with low FPS?
[10:02] Acheron Gloom: Alright.
[10:02] Acheron Gloom: Thanks so much for all your answers, Kelly. :)
[10:02] tehKellz (kelly.linden): (and we adjust the time to next to account for however far we missed the actual time it should have happened)
[10:02] tehKellz (kelly.linden): Thanks everyone for coming!
[10:03] Qie (qie.niangao): thanks Kelly
[10:03] Nal (nalates.urriah): Thx Kelly
[10:03] Ima Mechanique (nielarcher): thanks for having us ;-)
[10:03] Liisa Runo: thanks everybody
[10:03] Kallista Arliss (kallista.destiny): thank you