Script scheduling confusion
planned
Frio Belmonte
Not really a bug, but I'm curious what's the logic here: I have my Game of Life gadget running at full blast, set to a glider pattern so its performance should be deterministic. It can compute about 24 frames per second, with the target timer set to maximum at 45 fps.
I make an identical copy of the gadget and reset them both to the test pattern. The old copy now computes
28-29
fps, and the new copy, with the exact same script asset, runs at ~24-25 fps.How does making a new copy of the same script running busy calculations at max pace speed up the original one, and the copy is also on average a little bit faster? If I recompile the new copy with a tiny change to ensure they're not the same asset, the speeds remain the same. If I stop the new copy from running, or give it a very slow timer rate like 1/s, the first one returns to 24 fps.
Really not a big deal, though demanding scripts
speeding up
other scripts on the region just confuses me and it's hard to side-by-side compare finetuned versions... it could of course just be an artifact of the timer resolution and how the scripts attempt to measure the timings (it's a simple "count frames, once time_delta >= N seconds display the frames/delta, reset frames" method), but it's curiously consistent in how it behaves.Log In
H
Harold Linden
marked this post as
planned
H
Harold Linden
marked this post as
under review
H
Harold Linden
As a general rule of thumb, if the scheduler does something that doesn't appear to make sense, it probably just doesn't make sense :) .
Does this repro with LSL-Mono as well?
Unfortunately, the scheduler is more-or-less the same as it is on the production grid, SLua scripts just wear a trenchcoat with a name badge that says "yes I am an LSL script please schedule me". We've done a lot of work to reduced the _overhead_ of the scheduling algorithm over the past few months, but the core scheduling logic is mostly the same aas it's always been, since it's nigh un-testable.
Once SLua is stable-ish I'm going to rewrite the simulator's script scheduler to be more sensible and testable, but I'd be interested to know if this is _new_ behavior with SLua. I want to say I've seen this before, and it's not new behavior, but I'm not entirely sure.
Frio Belmonte
Harold Linden Backported some monitoring to the original LSL-Mono version and I
think
I'm seeing the same, although the difference isn't as noticeable (one copy runs at 12-12.5 fps, two copies both run at 13-13.5, but quite consistently so).As an added data point, I set it to LSL-SLua, this particular math is very unsuited for it and runs at half speed, but even there making a second copy affects the timing of one of them (this time it seemed random which one gains a tiny speed boost).
H
Harold Linden
Frio Belmonte I would not be at all surprised if it had something to do with which UUID (script or object UUID) is "higher" in value according to the sort order. The scheduler is currently full of
std::map
shenanigans and I've seen that pattern of misbehavior in other internal systems when iterating over the std::map
, since they iterate in key sort order.edited to add: but yes, that's definitely on my bucket list of things to fix.