Il giorno 25/ott/2011, alle ore 16:00, Lance Corrimal < lance.corri...@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
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
