[sldev] Multithreading, Garbage collection, Caching

[Skal Tura]

Hurliman: lol, i just wish people would actually start working on
performance.

Tleiades:

I think you are completely wrong on the bottleneck portion!

Computer A:
Core 2 Duo E6300
2Gigs Ram
GF 6600GT

Computer B:
Sempron 2700+ Socket A
512Mb Ram
ATI Radeon 9600 PRO

Similar FPS. I moved that radeon from computer a to b, and i saw way higher
FPS than i ever
saw before 6600GT on SL immediately.
Computer B runs SL about as fast as A, it depends on the situation.
So yes, CPU is the bottleneck, other core is constantly 100% utilized.

First Look viewer is even worse: FPS is actually way lower before i make
graphics options all
to about maximum. With default settings normal viewer gets about 20FPS, and
first look 8-14.

Even now, normal viewer has 25-28FPS, and i see only some ground, a tree,
one box and a
bumpammepd wall, and something small on the corner.
FPS visits now and then 20FPS.

After SL has run long enough, prims start to flicker, and it freezes every
now and then for couple
of seconds. Nope, no heat build up. After restart works fine. So it
DEFINATELY leaks badly.

Note that i might run SL 10hrs straight, sometimes even more. I have a
business inworld which
needs constant attention.

About the threading: Some portions would be easy to multi-thread, really,
make some complete
portions run in a separate thread, don't make new threads, don't kill old
threads, make them stay
on the same thread, unless user action requires a new thread, and killing
old.

Ie. Sound subsystem would probably be very easy, and i think i would
instnatly see a 10%
performance increase.

Also, you are wrong about the part that there is no use using multiple
threads without multiple
cores, performance wise.
Well, what happens in a single-thread, single-process app when some function
all of sudden
freezes for a moment, waiting for Disk I/O, Network I/O or something along
those lines?
Whole app freezes for that time period. This is MOST likely what i'm
experiencing.

Oh yeah, and i don't have I/O bottlenecks neither :) SL, Windows, most
programs work on a
SATA-2 HDD which was fastest consumer hdd when i bought it -- couple months
ago.
And my home server / firewall / pseudo proxy, never see a load above 0.10 :)
and runs on a
SCSI Raid 5, slow cpu & little slow speed ram, but they aren't bottlenecks
as it's quite dumb
system. Net connection being 8/1Mbps ADSL.

So i guess, we can completely wipeout resource bottlenecks.
What we can conlude here is having viewer which is unable to utilize all the
power.

If i wuold have time, i would first look into multithreading, then graphics
calculations: are the
formulas used fast? (Know the InvSqrt function of Quake 3? ;) ) and do we
render stuff we don't
need.

Processing power spent to reduce processing needs, I/O and enhance the
amount of used resources etc. imho is well spent processing time if done
sensibly.

Also, does the viewer render all sides of a prim even the non viewable ones?
That's PLAIN
stupid. Remember MKD(game) or Kyro 2(Vid Card)? Both made a huge deal of
getting rid of
unnecessary threading, end results were stunning. Kyro 2 had some under half
or so of the
transistors of fastest vid cards at the time, yet it was one of the fastest
in most applications.
It was all wisely spent processing time.

Other thing is that GPUs can do a great deal of other stuff also than just
graphics calculation,
perhaps that could be utilized in SL also? GPU is for certian type of
calculations so many times
faster than than CPU.

Imho, it makes perfect sense to run SL in many threads, and not just the
amount of cores.
You should do some background checking on benefits of threading, and look
especially on
server side applications ;)

There is a reason why ie. Apache is run in so many processes / threads,
default being 150.
(Apache 2 is afaik threaded and 1.3.x uses child-processes. I use only
1.3.xdue to production
stability, security and compatibility reasons).
It allows apache to be lightning fast ... But wait, it's not even the
fastest one out there!
There's couple httpds which are WAY faster than apache on heavy load: Again,
massive
multi-threading allows that :)
http://www.lighttpd.net/benchmark look at the bottom. when reading from
disk, best throughtput
was acquired thru using 64 threads for disk i/o!!
Now, HDD is one which you'd think that only 1 request can be done at once to
achieve best
performance, but then what is this what we see here?
Ok, this guy uses RAID -1- it's striped, but only 2 disks, and no data of
striping block size, but
it seems he used software raid (md-driver) and SATA disks, which are able to
hold a queue of
tasks.
Yet on that setup, one large file request needs both disks and a lot of
seeks, so there's a downside also.

damn this is getting long, but i hope i'm getting my point clear.

Threading == Good
No Threading == Catastrophic

Oh yeah, on my own tests ages ago, i saw a clear performance increase in
using threads on a single cpu, and obviously, single core :)

Now is it hard? By your description yes, and there comes in code
refactoring, which should
be done always anyway. First do it quick'n'dirty, fix the bugs, then
refactor, test, refactor, test, refactor, test, until you are happy with
stability, clearness of code and performance.

You can do a recursive function to get recursive data from DB, but you can
also just write a recursive query... Which is better? The query obviously,
DB is easier to balance and it caches
the queries & results :)


Network bottleneck:
As it currently is, SL uses very little of the available BW also, this is
very annoying. I know i can
get fast from states also, but it's ridiculous to use just 10% of available
bandwidth.
Even at best i'v eseen only 1200Kbps used, but that's very rare!
Usually i see 400-600Kbps, and even sometimes i see some 20-60kbps and many
textures
unloaded.
A 256kbps connection can get 29491,2Bytes per second (10% error correction
waste) so it
ain't much, but it also is quite a lot. For example, counter strike
generally uses under 20k/s,
even for 32player server :)
And if you played it -- You know that fast reaction is a key, there's
difference between 10ms and
20ms latency which can be thru metrics noticed! (Playing performance,
accuracy, kills, deaths etc.)
Altho, no physics is calced on counter strike at the server side etc. etc.
etc. but the rate of
updates is insane on it. and on SL i generally see some 12 agent
updates/sec, and something
like counter strike requires hundreds of updates / player / sec.


Oh yeah performance wise:
SL is dead slow right now, go play games and you know!
It's funny to see that zooming as close to terrain, raises FPS only to 34-36
range :D
And going to height of over 1600, yields spikes of 69FPS, but FPS is quite
jumpy.
On that height, only avatar, UI and sky texture, we should see way over 100.
Looking at pitchblack yields interesting results, at best 85FPS but now and
then drops to even 30.... generally jumps 73-85 range.
Do you call this well performing? If so, i hope you only do personal stuff
:)

On pitch black:
KTris drawn 0.3/fr, 28-29/sec
Total Objs 2349-2351
New objs 0/sec
Pipeline
Visible drawables 19-20, Faces 56-58, DirtyGeom 103-104/fr, DirtyLight 0,
Movelist 33dr, Compiles 54-55/fr, Vers Relit 0/fr
Texture count 498, raw count 25, GL Mem 95.5, Formatted Mem 3.9, Raw Mem
82.4, Bound Mem 2.9




And now, i'm not going to buy older hardware to get SL running better, or a
1,000€ CPU and 600€ Vid card!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070318/f81d2816/attachment-0001.htm