On Sat, 2007-12-15 at 13:34 -0800, Eric Anholt wrote: > On Sat, 2007-12-15 at 11:07 -0700, Brian Paul wrote: > > Keith Packard wrote: > > > The pthreads library introduces significant overhead for single-threaded > > > applications, > > > > Just out of curiosity, have you made some measurements? > > As keithp noted, we were seeing 5-10% CPU time in pthread mutex > operations depending on the app being profiled on 965. It's gone with > the dri_bufmgr pthread removal I did, but I've later realized that we > can't just do that, since buffer objects are shared between contexts > (ugh), so the bufmgr internals will need to be protected from concurrent > access and those costs will be coming back.
For ref counting, gcc has atomic inc/dec operations these days, so we should be able to use those to limit the cost here. The real issue here is not in our libraries or test applications. Consider a "real" single threaded application which happens to use stdio. Linking in the -lpthread version of that library turns out to be a disaster for thinks like putchar/getchar, so we're imposing cost on all applications when we support any threaded applications, unless we either force applications to tell us when they need locking (ala XInitThreads), or use the weak symbol hack. > We're already pulling in libpthread-stubs if XCB is being used, and when > someone gets around to it libX11 will use it as well. Getting our > required stubs in there sounds like the right plan. Sharing the same library makes a lot of sense, unless I can figure out how to get our libGL stubs built into libGL itself. If I can manage that, it seems like adding a non-standard external dependency is less overall misery. Although, one wonders what kind of disaster will strike if we end up duplicating these pthread symbol replacements. Ideally, I'd manage to convince Ulrich to add them to glibc as it already provides many pthread functions. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
