|
|
|
i can confirm this. i had help from an estate owner to test on my vendors in lsl and mono. the vendors are most of the time idle except for having a listener and a timer, accounting for their idle time.
compiled in lsl, between 0.001 and 0.002. compiled in mono. between 0.002, and 0.003. sometimes all readouts are lower, then the lsl ones are more often 0.001, and the mono ones are between 0.001 and 0.002 but more often 0.002. i'd say the difference is in the order of 0.0005 comparing idle script times of lsl2 versus mono
My thoughts were that Mono would run faster, my initial tests show some things do and some things dont. I personally feel that this will involve new tweaks by scripters and by LL themselves to once more find the way to squeeze performance out.
When you are looking at the script time in Estate Tools it is expressed in milliseconds (1000th of a second) 0.002 to 0.003 is a negligable amount that could be influenced by sim performance, other scripts, number of agents during the two tests and so on. To see/repro an increase of 150% you would really need to look at an object with much higher timings. The linden recommendation for LSL is that 5ms should the total script slice in a sim for decent lag prevention. I realise that vendors by design normally are installed in large numbers, but this in my opinion isn't altered much by a 0.001ms difference. Shiban – multiply that figure by 4000 (the average number of scripts on a well-used sim) and then add that to the script time per sim frame. You'll see why even your own conservative estimate represents a potentially highly significant issue.
OK, this is ridiculously easy to simulate provided you have a friendly estate manager (or you are one .. an estate manager that is; don't know if you are friendly).
Create two objects. Put identical code into both of them. Keep them simple .. a passive listen event (i.e, not enabled by llListen), a link_message, a touch event and an empty timer that fires every 100 seconds. Call one of the objects 'test script - mono'; the other 'test script - lsl'. Now use estate tools and look at performance of BOTH of them (i.e, they are both subject to same "sim performance, other scripts, number of agents"). Tadaaa .... Mono slower than lsl in quiescent state. (3us against 1us for me on an openspace sim) Now .. for many scripts the first two items are common (if you've split your script up it's likely you have a link_message). The comment that Escort makes above is scary but valid .. many scripts have a significant quiescent value and in that state, the script is slower. Does that mean the sim will slow down? Only Lindens know .. and come on people, given the simplicity of the test don't you think they DO know about this one? .. it's rather a basic test My guess is that there's debug code left in the mono compiler that slows stuff down, but i'm only guessing. Have to wait for a Linden to pick this bug up to find out, but until they do, there's no way I am recompiling all my scripts for mono on my openspace sim. I noticed this one also before reading about this here.
All Mono compiled scripts use more cputime while idle compared to LSL scripts. So the question is, has something changed how this is maybe calculated or mono scripts are handled, that would make the sim don't lag on the same values that LSL did cause lag, so we can expect thousands of idle scripts will not require more resources or less scripts would not lag a sim earlier in Mono or will this really cause more lag if everything runs in Mono? Are there reasons for that (like the debug code stated) that we can expect soon to have better performance? I noticed this too, but I figured it was just an error in the software used to measure script time. Those numbers do seem to lie.
Right now the sim I'm in, from the "Top Scripts" window, it says: "119 scripts taking a total of 2.4ms" What does it say in my statistics window for the sim? 10.0ms And those numbers are steady. Dur.. Forgot that avatars aren't listed in the Top Scripts list.
I thought there was something in release notes or previous discussion that the instrumentation for mono scripts was not reliable, and that they would be accounted for separately from LSL2 scripts in a future rollout.
Avatars are listed in the Top Scripts if they sit on a pose ball. Then their frame time is shown.
Tesing where I am the only Av in my region and looking at the Top Scripts while I am sitting shows 4.4ms whilst the statistics window shows 0.8ms Argent – I've not seen that comment but perhaps it explains what the "mono time" column in the top scripts dialog is intended to be? In that case, a simple confirmation from Babbage, etc would at least resolve this issue, if such it is.
Yes, I confirm this one too. (from 0.047ms in LSL to 0.140ms in Mono – same script).
It would be nice to know if it is reliable or not. And if we should look at it or not. Thank you i have done an experiment to see how mono versus lsl idle scripts affect sim time. this has been done in a normal sim.
i used a script with a timer and an active listener. there does not seem to be any difference. also i have (again) found that using lots of scripts does not lower the sim framerate, it only slows down scripts. atleast in a clean experiment situation. before testing: MONO, 1 script per object LSL2, 1 script per object MONO, 5 scripts per object LSL2, 5 scripts per object MONO, 5 scripts per object LSL2, 5 scripts per object MONO, 5 scripts per object LSL2, 5 scripts per object this means idle mono script don't really use more time, but their times as displayed are wrong, so if anything has to be fixed, this is it. Babbage, can you comment on this?
Babbage explained this phenomenon at his office hour.
Check [8:44] and related chat. http://wiki.secondlife.com/wiki/User:Babbage_Linden/Office_Hours/2008_09_03 With ref to Nock's link .. there's a lot of stuff .. I've 'tried' to extract out the items that are relevant to this Jira report. I'll redit this comment when Babbage picks this up since the office hour conversation was cluttered and some things said out of sequence
=================================== Babbage: i'd be interested in seeing mono using more processor time too. it may use slightly more when scripts are doing nothing as mono scripts check whether they need to migrate when they're run mono has to convert strings to utf-8 when passing them to library calls implemented in C++ that could take longer which is the common case but in generally Marshalling data from Mono to C++ is very fast Q. what about those reports about using more cpu time? could it be that all SIM monitor tools are not yet optimized for Mono? Babbage: i'd like to see examples where running Mono scripts use more time than LSL. i haven't seen any examples yet just idle scripts using up slightly more time Q. does that idle time affect the sim, if there are alot of idle scripts , like in a furniture store that has poseballs in almost every piece Babbage: long term, idle scripts shouldn't consume any CPU time they should be moved to a non-running scripts list and only become runnable when they have pending events we have plans to address that but it may not be for a while in the meantime, i doubt the extra work mono scripts do would have a noticable effect even with 1000s of them in a sim Mono scripts need to check whether they need to migrate to another application domain when they run, which is work that LSL scripts don't need to do. This could account for the extra idle time.
Looking at the top scripts output above, it looks as though mono scripts are taking up to an extra microsecond per frame over LSL scripts, although it's difficult to tell as this is at the absolute limit of the top scripts resolution. Assuming a full microsecond extra, 1000 idle scripts converted to Mono would consume an extra 1ms of frame time compared to LSL. This is ~5% of our frame time allocation of 22ms, which is considerable, but only in this pathological case. A better solution would be to fix script scheduling so that scripts are never polled per frame when they have no events pending which would drop idle time to 0 for all scripts. This improvement is on our scripting roadmap, but I can't give you dates for it yet. Other cases where Mono might consume more CPU time than LSL include when large lists or strings are passed to library functions and need marshalling to LSL representations. In general I expect this overhead to be dwarfed by the gains of running JITed code, but it may be possible in some cases for Mono to use more CPU time. If you discover such a corner case please pass me a script which runs a simple repro demonstrating the problem in the state_entry handler. We have a test harness that can run scripts in that form through a profiler. I'm not reopening this issue, but from what I read above it seems to confirm that:
1) This is not a reporting error but a genuine increase in idle time. 2) Recompiling atll your scripts to Mono will (for the moment) increase your sim lag by about 1ms per 1000 scripts i.e. about 4ms on an average, well-used simulator). I look forward to the improvements in script scheduling that will offset this. While that may be true, don't forget that the actual time used to run mono scripts is much less, according to LL. It will probably make up for that extra idle time. Also, babbage pointed out that the numbers we're seeing potentially have a high degree of error, so 4ms may not be accurate for 1000 scripts. I mean, we're dealing with microseconds here.
I'm confused why there's still any debate on this issue after Beware Hax posted the results of his tests. By the looks of it, MONO scripts don't demand any more time than LSL2 when idle.
10042 scripts. Mono: 20.2ms LSL2: 20.2ms I don't see a difference? Alright, but what about his test with 4042 scripts? Mono being at 10.8ms and LSL2 at 10.7ms. Assuming there really is a WHOLE 0.1ms difference there...
A single idling mono script requires... 0.0000247402276ms more script time. Frankly Lex - your commentary (and it is just that) is counter productive. There is an effect. There is an issue, but it is far from clear even now whether the issue is owing to reporting or a genuine lag issue – my tests and beware hax' tests show it could be either. Babbage suspects that an indirect fix to script scheduling may improve matters. If you choose to read carefully beyond that this ticket is "resolved - won't fix" you will see that some effect is nonetheless there. Quite different to your assessment of "nothing to see here".
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Script Idle time increased under MONO recompilation
Is the estate time wrong, or is it right, but doesn't matter anymore because of some internal handeling etc. Any explanation would be greatly appriciated. 
I have personally spent a lot of time tweaking scripts to give the best performance, using the estate tools, so it almost hurts to see those scripts double in time
Is the estate time wrong, or is it right, but doesn't matter anymore because of some internal handeling etc. Any explanation would be greatly appriciated.