Performance Comparison: Openspace vs. Regular sims
|
Desmond Shang
Guvnah of Caledon
Join date: 14 Mar 2005
Posts: 5,250
|
07-25-2008 08:20
Andrew is extremely cool. I try not to waste his time, but he's basically the person to ask about these things. He's got a lot going on; I think we are going to see some wonderful changes to the grid for everybody, maybe even by the end of 2008.
_____________________
 Steampunk Victorian, Well-Mannered Caledon!
|
Sindy Tsure
Will script for shoes
Join date: 18 Sep 2006
Posts: 4,103
|
07-25-2008 08:55
From: Desmond Shang Andrew is extremely cool. Extremely. From: Desmond Shang I try not to waste his time, but he's basically the person to ask about these things. That's just what office hours are for! Sidewinder and Simon also frequently show up for Andrew's office hour, or at least they do on the Thursday ones. If you want to know more about how sims work, his office hour is a good meeting to be at. From: Desmond Shang He's got a lot going on; I think we are going to see some wonderful changes to the grid for everybody, maybe even by the end of 2008. 
|
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
|
07-25-2008 09:05
From: Darien Caldwell That's an interesting observation. One thing I've been doing to 'cause lag' is open a lot of listeners (88,000 or so). I found it really didn't cause any.
It really would be more accurate to say the lag comes from the scripts processing of the listener event, rather than the listener itself. Some people have a lot of processing going on in your typical listener event. Having the listener open itself is not laggy. If your Listener event quickly discounts any input as not being meant for that particular object, the additional lag will be minimal. How were you measuring the lag etc.? Opening 88,000 listeners almost certainly would have caused lag, but the question is; where? To get an actual result you need more than just the debug stats (script perf etc.) as chances are the scripts are being throttled heavily to handle these listens. Where the listens on all different channels, or the same one? Every single listen that is open will cause some lag somewhere. If you have 500 listens on channel zero, then every time a message is said near to those items, the simulator will have to go through every channel zero listen looking to see if the message meets the criteria for that listen. It then has to go through them all, copying the message into an event and giving it to the script. Maybe LL have switched from copying it to using pointers, but LSL isn't a very sophisticated language so I doubt it. Better tests for listens would be to do (in an empty simulator): 1. Create a "shouter" that constantly sends messages. 2. Create an item with a single listener script in it that listens on the channel of the shouter. 3. Create another item that tests the performance of loops/lists etc. (such as the simulator tester mentioned by the OP). Now, increase the number of listener scripts in the object (don't copy the object, as that introduces physics overhead). Now, with a large number of scripts you should get a notable difference in the performance of the tester script (item 3.). This gives you an idea of exactly how much script-lag a large number of listens introduces; as the performance tester gets slower this is the impact other people's scripts will have as a result of too many listens. A second test is this: 1. Create a "shouter" that sends a message when touched, noting the time it sends it. 2. Create an item with two listener scripts in it that listen on the channel of the shouter, noting the time they receive the message, and are capable of sending that value via link-message. 3. Create another script in item 2. which will collect the values recorded when touched (so link-messages aren't counted), returning the fastest time and the slowest time. Now you simple run the test by setting everything up, then touch the shouter so it sends its message. Wait a reasonable time to ensure the listeners are done and touch the object to get the fastest/slowest time, compare these to the time recorded by the shouter. This gives you a measure of how long it took for the message to arrive at the first listener, and for the last listener to receive it. Run the test with more listeners and you can get a good idea of how much lag is introduced between sending a message, and receiving it, due to the processing the simulator has to perform before giving controls to the scripts. I don't have an empty simulator so I can't run these tests to decide once and for all the effects of listeners.
_____________________
Computer (Mac Pro): 2 x Quad Core 3.2ghz Xeon 10gb DDR2 800mhz FB-DIMMS 4 x 750gb, 32mb cache hard-drives (RAID-0/striped) NVidia GeForce 8800GT (512mb)
|
Darien Caldwell
Registered User
Join date: 12 Oct 2006
Posts: 3,127
|
07-25-2008 12:18
From: Haravikk Mistral How were you measuring the lag etc.? Opening 88,000 listeners almost certainly would have caused lag, but the question is; where? To get an actual result you need more than just the debug stats (script perf etc.) as chances are the scripts are being throttled heavily to handle these listens.
Where the listens on all different channels, or the same one? Every single listen that is open will cause some lag somewhere. If you have 500 listens on channel zero, then every time a message is said near to those items, the simulator will have to go through every channel zero listen looking to see if the message meets the criteria for that listen. It then has to go through them all, copying the message into an event and giving it to the script. Maybe LL have switched from copying it to using pointers, but LSL isn't a very sophisticated language so I doubt it. 8 objects opening 11,000 listeners each, channels 1-11,000. so each channel has 8 listens on it. sure, there is likely overhead for opening a listen. But I'll try to word my point differently. Aside from the minimal sim overhead of having a listen, a listen that receives no input will generate no script load. The old saw that 'listens are laggy' is a misnomer. The processing of listener input is what is laggy. If you have a listener on channel -3493894 and nothing is ever said on that channel, it's not going to make a perceptible amount of difference to the sim's script load. Your test of shouting at the listener would, since that causes the listen event to be invoked  Naturally a script that is doing something will cause script load. 
|
Talarus Luan
Ancient Archaean Dragon
Join date: 18 Mar 2006
Posts: 4,831
|
07-25-2008 13:29
From: Darien Caldwell 8Aside from the minimal sim overhead of having a listen, a listen that receives no input will generate no script load. The old saw that 'listens are laggy' is a misnomer. The processing of listener input is what is laggy. If you have a listener on channel -3493894 and nothing is ever said on that channel, it's not going to make a perceptible amount of difference to the sim's script load. Actually, the "old saw" wasn't simply that open listens contributed significantly to lag, but that significant numbers of open listens on the same channel, and especially channel 0, contributed significantly to lag, as you ascribe. That said, many open listens CAN make a difference in sim performance. For example, open up 100,000 listens on a range of channels, and then flood some other channel outside that range with chat messages. You should see a noticeable performance dip, even though none of the listen events were triggered. The reason why is obvious: there is some sort of list structure that must be checked every time a sim processes a chat message. The first check is only the channel check, but even scanning a list of 100,000 32-bit integers for a match takes time. From reports on the old lslwiki, there starts to be significant degradation on sim / script performance at 100k listens, getting worse the higher one goes. Only a few misinformed souls clamor against all listens, but still, minimizing the numbers, especially in popular products that people use a lot, is a good idea.
|
Darien Caldwell
Registered User
Join date: 12 Oct 2006
Posts: 3,127
|
07-25-2008 13:45
From: Talarus Luan Actually, the "old saw" wasn't simply that open listens contributed significantly to lag, but that significant numbers of open listens on the same channel, and especially channel 0, contributed significantly to lag, as you ascribe.
That said, many open listens CAN make a difference in sim performance. For example, open up 100,000 listens on a range of channels, and then flood some other channel outside that range with chat messages. You should see a noticeable performance dip, even though none of the listen events were triggered. The reason why is obvious: there is some sort of list structure that must be checked every time a sim processes a chat message. The first check is only the channel check, but even scanning a list of 100,000 32-bit integers for a match takes time. From reports on the old lslwiki, there starts to be significant degradation on sim / script performance at 100k listens, getting worse the higher one goes.
Only a few misinformed souls clamor against all listens, but still, minimizing the numbers, especially in popular products that people use a lot, is a good idea. Yes, that makes a lot of sense. Naturally nothing you do in SL (or outside of SL) comes for 100% free. I tried to word my statement carefully with a lot of 'noticeable, significant, substantial' type adjectives And honestly, I hope there's no widely popular items opening 100,000 listens. But it does change my outlook on listens a little. I was afraid to have 3 listens open on a product i was working on because of the fear of lag. but I may just open that 3rd one after all. 
|
Argos Hawks
Eclectically Esoteric
Join date: 24 Jan 2007
Posts: 1,037
|
07-25-2008 15:18
From: Desmond Shang He's got a lot going on; I think we are going to see some wonderful changes to the grid for everybody, maybe even by the end of 2008. All right, Mister! You've got to spend an hour in the corner (or a crowded infohub) for teasing everyone like that without giving any details.
_____________________
Step 1: Create virtual world Step 2: ??? Step 3: Profit
|
Darien Caldwell
Registered User
Join date: 12 Oct 2006
Posts: 3,127
|
07-28-2008 12:05
For those that may be interested. I finally received my openspace Mono sims on the beta grid late last week. After some work and some discussions with the Mono team, My results are inconclusive. This is mainly because my sims were placed on Class 4 servers on Beta, so I can't do a proper comparison to the Class 5 sims on the main grid.
However, Comparing Class 4 LSL Openspace to Class 4 Mono Openspace, there was some minimal gains in script performance. So I can extrapolate there should be some gains under Class 5 as well. But only time will tell.
On a different note, This gave me a rare opportunity, as all 4 openspaces are sharing the same Core, in this guaranteed and verified (by LL) scenario. I can say with some certainty that lagging the bejesus out of one Openspace had no discernable effect on the other Openspaces sharing that core.
If anyone would like to do their own tests, contact me and we can arrange something.
|