[sldev] Multithreading, Garbage collection, Caching

[Tleiades]

I doubt I can answer all your questions, but maybe I can help shed a little light, on some of your questions.

Adding an additional thread of execution is, as you point out, actually quite simple, it can be done crossplatform as a virtually nobrain excercise. But getting two or more threads of execution to run without getting in each others way is the difficult part, the classical example is this one:

create a procedure like this:

Global shared variable: counter = 0

for int i=0 to 1000
begin
    add 1 to counter
end

now create two threads, both executing the same procedure as above, the two threads will share the global variable, and execute silmutaneously. Intuitively you would expect that when both threads terminated, the counter variable would be at 2000. Unfortunately in the real world, that is a very unlikely outcome, since the two threads will compete for the same shared resource. I.e. you need to ensure that the threads do not interfere with each other.

Mechanisms for handling shared resources are tricky, and implementing this in the code base of an application of any decent size is a tremedous task, especially when it hasn't been designed into the architecture from the outset. Implementing multithreading will require major changes across the codebase, and LL has clearly stated that any major changes which is intended for general viewer will have to be approved before hand.

Second, multithreading may hurt the performance of an application rather than improve performance, in a well designed application it will rarely make sense to have more threads than you have CPU cores. An application can be seen as a stream of instructions which needs to pass through a CPU core, it doesn't really matter to the CPU if you have 2,3,4,5 different streams (threads) it still cannot handle more streams than it has cores. In addition, now you have to pay CPU time to schedule which thread should be executed, and instructions needs to be added to handle locking of shared resources, multiple threads come with a price tag of:

1) additional work for the task scheduler
2) additional instructions needs to be executed for dealing with semaphores, signals, mutex'es etc.

When all is summed up, you may - depending on the application you are working on - discover that multithreading degraded performance rather than improved upon it.

For a dual core, quad core or hyper threading cpu additional threads may still make sence, but adding shareing of resources to an existing application is no small feat.

Third, - I admit this is speculation - but I doubt that CPU is the true bottleneck for the SL viewer. My first guess would be that the reason behind the low FPS rate of the viewer is due to the number of render calls made. Assigning a new task to the GPU is a very costly operation, GPU's execute blindingly fast, but every time it is assigned a new task, a huge performance hit is made. In a traditional 3d application huge amounts of time are spend, planning and preparing the graphics scenes, in order to reduce the the number times the GPU has to change tasks while rendering a frame. In SecondLife this isn't possible, users create the content, and the number of times the GPU has to switch tasks may skyrocket depending on how the users created the content. Let me give an example: If you create a simple cube, and add a different texture to each side, you may end up in a scenario where you send 6 render tasks to the GPU just to render one prim. Now imagine that for thousands of prims, in the region, as attachments to avatars, etc. each needs to be rendered every frame. I admit I haven't dug into the SL render pipeline, but my best guess is that this is the real cause of the frame rate we are seeing in SL.

SL is written as a native c++ application, i.e. there really isn't such a thing as garbage collection, I would be surprised if SL didn't have the occasinal leak, but I don't feel any serious performance degradation over time.

Again, I haven't really looked into the cache managment subsystem, it sounds as if there is room for improvement. Having said that, I agree with you that assets should be retrieved via HTTP, I don't have intimate knowledge about the architecture behind the LL asset servers, but between comments I have read and my own guesses based on those comments I doubt that neither the asset servers nor the simulators can scale to internet size.

Allowing assets to be retrieved via HTTP, and allowing any URL, users could store prims, textures sounds etc. on any web server on the internet, greatly reducing the load on the SL asset servers, allowing - as you point out - local caching proxies to store the content etc.

On the other hand, getting the asset servers to scale is really not that difficult, well known public methods are avilable for that, getting the sim's to scale - IMO - will be next to impossible, imagine a concert in a sim with 10.000 avatars, each moving and talking, and your 256Kb connection has to download all those chat and agentupdate messages.

----- Original Message ----- 
  From: Skal Tura 
  To: sldev at lists.secondlife.com 
  Sent: Sunday, March 18, 2007 1:21 PM
  Subject: [sldev] Multithreading, Garbage collection, Caching


  I'm wondering that is anyone working on multithreading?

  Personally, i haven't looked into source code even more than a glance,
  but i heard that SL Viewer uses FMOD for sound, right? I know that atleast
  it is quite easy to multithread. (about trivial)

  Also timers, rendering(or should i say, objects and their polygons calculation) are trivial
  to multithread on a traditional app. Hell, i've seen for visual basic a library which allows one 
  to call "ThreadThis" function, which essential takes pointer to function and parameters as options,
  and runs that function in a separate thread.

  So why is it so hard? I use Dual core cpu, and SL runs slower on my machine than on crappy, 
  years old office computer!

  Ofc, this is my opinion, i only know that years back when i first time coded something with
  C/C++ i went straight into multithreading -- I were making an 64k demoscene entry for assembly, 
  and that was a must, funnily, threading portion was easiest :)

  Oh yaeh: Multithreading doesn't necessarily need straight away to be multiplatform, it's going
  to be platform specific portion, like it not, but that ain't a big deal, just keep it simple :) 


  Garbage collection:
  It has started to seem that garbage collection is "somewhat" lacking, i see SL taking constantly
  more and more memory, and starting to run slower and slower each passing hour. 
  Could someone clarify this, perhaps some numbers?


  Caching:
  Why for the ffs caching is done that badly? Asset server load could be easily cut to half if it
  would been done better!

  Let's say i'm at place A, where i am very often, i goto place B, spend there 10minutes, and come 
  back to place A --> All textures are being loaded again... Slowly.

  Scenario two: I'm at place A, and then i create some small object there, and script it a bit, spend
  some 20minutes with it.I press esc to return view and turn around: Yay, it's downloading the 
  same textures, YET AGAIN! :D

  SL already uses unique ID for each texture, and this unique ID cannot get "updated content" meaning, texture changing. Why doesn't SL get the tex's once, and keep them forever after that? 
  Why doesn't SL do any kind of record keeping where a specific user spends his time to choose
  which portions of cache to preserve?

  Also, does static content come which way? If it would come via HTTP (and port 80 for those who 
  have pseudo proxies!), it would be lightning fast. Yet it could be secure, no directory listing, and
  say a pointer has to be asked from a separate system perhaps?
  A fast PHP based, and MySQL backend system, wouldn't even require too much :) 



  That's a lot of criticism and questions, i enjoy reading what's going on behind the scenes to
  make SL better, but i still dont' see anyone working on the most crucial parts of the viewer.
  Why is it that? Doesn't anyone care about performance?

  I hate the fact that i can run any game with high settings, with good FPS, but when it comes to
  SL, i actually gotta turn graphics higher to get over 20FPS. 

  And for those who are going to say something about drivers: All drivers are latest, settings optimized where applicable. I have an overclocker background. (with air, 1.33Ghz Tbird to 1.77Ghz stable, beat that! or with air again XP 3000+ at 4400+, stable at ~4000+, give or take 100) 

  Oh yeah: I don't currently run overclocked system (and don't intend to), but the cooling is there.


  Thanks,
    Tyrian Camilo

  PS. I haven't coded with C/C++ in several years, but guess i could dig out my old source code to see how i did threading back then. 



------------------------------------------------------------------------------


  _______________________________________________
  Click here to unsubscribe or manage your list subscription:
  /index.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070318/b73ddcfb/attachment-0001.htm