[sldev] Multithreading, Garbage collection, Caching

[Skal Tura]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070318/c69e71e2/attachment.htm