[opensource-dev] Question about speed of name cache query

[Francesco "Sythos" Rabbi]

Il giorno 25/ott/2011, alle ore 16:00, Lance Corrimal <
Lance.Corrimal at eregion.de> ha scritto:

All I know about name caching is this:

clear your cache the hard way, by removing everything in the cache
folder, then open the info tab of a group with a really high number of
members, and your framerate will go to hell until all display names
have been fetched.


Am Dienstag 25 Oktober 2011 schrieb Jonathan Welch:

For my solution to Storm-1653 (Group notices sent by muted

residents are still displayed) I have to call

gCacheName->buildLegacyName to get the AgentID associated with a

legacy name.


It looks like this code may operate asynchronously if there is a

cache miss.  In my testing I was always able to get an AgentID

back, even with a cache miss, but my tests were not being done in

a lagged out region.


Would someone with knowledge of the name cache tell me if it is

possible for this routine to not return an AgentID; I'd like to

comment my code change properly.


During my experience in KV team i've tried lots of way to increase
performances, pthread (actually used) have the "bad side" to hold the parent
thread till the job is executed if the next token of parent thread, APR
solve a bit deploying some loads on separate threads, but for intrinsic
nature of pthread (APR is just a wrapper like boost::thread) the child have
a lot of constraints from parent thread. This mean some code token can slow
down (till hand for short time) the main thread.
I've stepped in my test in 2 directions: OpenCL and OpenMP (not for
"release" of KV, just few test with very few tester).

OpenCL require a lot of code rewrite, i've tried just to spread main threads
(cloning the main thread incipit like in macosx code, on Mac OCL is native),
the performance are higher, but not so much as the pain of rewrite the code
(and is a lot driver dependent, nVidia implementation and AMD/ATI one don't
match fully at 100%). OCL load GPU too if main CPUs are full, this mean
after a TP a overrall hang for 1-2 seconds while GPU move back to main
memory their threads and begin to work as graphic unit (at least... on my
system... not so high-end one)

OpenMP isn't so widely appliable, is pretty nice on thread startup code
(i've seen *ALL* my 4 cores loaded at 100%, just moving principal threads
like whole decoding and fetching thread on other cores via OMP), but is lot
interesting in "for" code, like inventory or name fecthing, OMP is very low
as invasive level and need few include and few pragma around the code. OMP
is native too on MacOSX, is a default installed lib on quite all linux
distros, is just a DLL on windows (another 3p libs and all should work). In
a child process hang or overload the core others PU can continue to work
without too many slows.

hoping this comment can be usefull, if more detail needed i can write more
(during european evenings, now "theorically" i'm working in RL ;) )

-- 
Sent by iPhone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20111025/f09e0d41/attachment.htm