Profiling was "Re: [sldev] Multithreading, Garbage

[Skal Tura]

When i look this i find it very interesting that ANY IdleLoop is being done!
Could someone compile for me firstlook with IdleLoop not idlelooping lol?

(i don't have even compiler atm)

Multithreading option was new for me, i haven't used first look for sometime
since when there
was some alpha rendering order problems.

What i find interesting altho is that either window's basic CPU usage charts
bug (doubtfull) or
something else, i see SL using with normal viewer both cores yes, but upto
50% maximum, and
spiking to ~65%. It's more same amount on each core with first look, but
only small benefits.
Difference between min settings and max settings just doesn't seem to be
great neither in it.
But total rarely exceeds 50%, when new stuff is loaded, it spikes to 52%.

My own approach for heavy duty calculation has always been:
- Precache everything & organize the data
- Calculate
- Save

And time after time it has proven to be the fastest method :) Altho, loading
/ startup times has been longer, but way more scaleable. Tho, this is
somewhat comparing apples vs. oranges, as
i code different kind of things than sl due to lack of time.


That profiling was quite interesting indeed.

Also, no matter how you put it, threading is the way to go, it's the future
minimum requirement,
there will be time when it's absolutely necessary, we already have quad core
cpus out there on
market, and they have plans of upto 64 core cpus, and some speculators even
say that in future
there will probably be hundreds of cores.
Even if those core amounts doesn't realize, you must realize their other
plans, and what is happening already: Assisting processors for specific
tasks.

Remember when computers had co-processors? That time is coming back --
except in each
socket can be a processor for specific task. Like now you have vidcard, and
there's GPU.
GPUs are coming to your motherboard. Know PhysicX or something like that
what it's called?
A card made just for physics calculation. Creative X-Fi can be called as a
Audio Processing Unit or APU. Also there's a network card with a powerfull
processor, and FPS players, PROs mainly,
use them, they give only slight advantage, but it gives an advantage.


So no matter how you put it -- You CANNOT be stuck on yesterday's coding
methods.

Multi-threading is a must.

Ie. if texture fetching isn't multi-threaded now, that's a huge bottleneck,
internet is always slow.
I'd do also fetching of textures, objects etc. in 8-16 simultaneously
running threads, what ever
is the set maximum for the server side to accept, but i would also throttle
it so that it doesn't
innecessarily flood the server, no reason to run 16 threads if just 20
requests to be done :)

I agree that one should use non-blocking I/O, but that isn't a solution
really.

SL is a slow behemoth right now, lots to improve.
I'd understand SL being slow, if it had today's graphics, what it does not
have, by far.

The portion which makes SL slow, is somewhere there, it might be tricky, or
it might be so
simple that it's almost impossible to notice.

You all here who are familiar with SL's code and work with it, You are the
guys to do it, You
have the expertise and familiriaty to do it. Not me -- I'm here just
complaining and whining,
partly becuase of my lack of time, partly because i haven't coded anything
similar in so many
years.

I can test with my setup for anyone who starts to work on removing the
bottlenecks, just tell me
what data to collect and with what, and i'll do it.

My system is as follows:
Windows XP Pro, latest patches always
2Gb DDR-400 Dual Channel
Core 2 Duo E6300
GeForce 6600GT 128Mb AGP
SL & Windows runs from a fast SATA HDD

Be bold when testing :)

What i would do first: Get my hands dirty into that IdleLoop: If it really
does nothing, Disable it
and see what happens >;D

Oh yeah, when i ran first look, i noticed that texture loading was VERY
fscked up. Had to wait
really long for textures to load.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070318/2dbb2922/attachment.htm